What one do you prefer? sorry im curius, i prefer Flash 
Do you prefer Flash sites Or Plain?
Me too.. I don't know why.. but I feel flash sites are much more visually attractive than plain websites..
Same here with something flashing and moving on the screen it always gets attention
I prefer sites that don't use flash for various reasons, namely because it is unfriendly toward the blind, and flash is just flash for sites that don't need to use it and I feel it's just a waste of bandwidth to use flash unless you own Newgrounds or a corporate homepage where you only spice up the site just a little bit with flash to impress potential buyers, but keep the main content textual.
hmmm... i see your point but i mainly do it to impress my mates at school lol.
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document defines an architecture for implementing scalable
service differentiation in the Internet. This architecture achieves
scalability by aggregating traffic classification state which is
conveyed by means of IP-layer packet marking using the DS field
[DSFIELD]. Packets are classified and marked to receive a particular
per-hop forwarding behavior on nodes along their path. Sophisticated
classification, marking, policing, and shaping operations need only
be implemented at network boundaries or hosts. Network resources are
allocated to traffic streams by service provisioning policies which
govern how traffic is marked and conditioned upon entry to a
differentiated services-capable network, and how that traffic is
forwarded within that network. A wide variety of services can be
implemented on top of these building blocks.
Blake, et. al. Informational [Page 1]
RFC 2475 Architecture for Differentiated Services December 1998
Table of Contents
1. Introduction ................................................. 2
1.1 Overview ................................................. 2
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 12
2.1 Differentiated Services Domain ............................ 12
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 13
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 14
2.3.1 Classifiers ........................................... 14
2.3.2 Traffic Profiles ...................................... 15
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 16
2.3.3.2 Markers ........................................... 16
2.3.3.3 Shapers ........................................... 17
2.3.3.4 Droppers .......................................... 17
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17
2.3.4.1 Within the Source Domain .......................... 17
2.3.4.2 At the Boundary of a DS Domain .................... 18
2.3.4.3 In non-DS-Capable Domains ......................... 18
2.3.4.4 In Interior DS Nodes .............................. 19
2.4 Per-Hop Behaviors ......................................... 19
2.5 Network Resource Allocation ............................... 20
3. Per-Hop Behavior Specification Guidelines .................... 21
4. Interoperability with Non-Differentiated Services-Compliant
Nodes ........................................................ 25
5. Multicast Considerations ..................................... 26
6. Security and Tunneling Considerations ........................ 27
6.1 Theft and Denial of Service ............................... 28
6.2 IPsec and Tunneling Interactions .......................... 30
6.3 Auditing .................................................. 32
7. Acknowledgements ............................................. 32
8. References ................................................... 33
Authors' Addresses ............................................... 34
Full Copyright Statement ......................................... 36
1. Introduction
1.1 Overview
This document defines an architecture for implementing scalable
service differentiation in the Internet. A "Service" defines some
significant characteristics of packet transmission in one direction
across a set of one or more paths within a network. These
Blake, et. al. Informational [Page 2]
RFC 2475 Architecture for Differentiated Services December 1998
characteristics may be specified in quantitative or statistical terms
of throughput, delay, jitter, and/or loss, or may otherwise be
specified in terms of some relative priority of access to network
resources. Service differentiation is desired to accommodate
heterogeneous application requirements and user expectations, and to
permit differentiated pricing of Internet service.
This architecture is composed of a number of functional elements
implemented in network nodes, including a small set of per-hop
forwarding behaviors, packet classification functions, and traffic
conditioning functions including metering, marking, shaping, and
policing. This architecture achieves scalability by implementing
complex classification and conditioning functions only at network
boundary nodes, and by applying per-hop behaviors to aggregates of
traffic which have been appropriately marked using the DS field in
the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to
permit a reasonably granular means of allocating buffer and bandwidth
resources at each node among competing traffic streams. Per-
application flow or per-customer forwarding state need not be
maintained within the core of the network. A distinction is
maintained between:
o the service provided to a traffic aggregate,
o the conditioning functions and per-hop behaviors used to realize
services,
o the DS field value (DS codepoint) used to mark packets to select a
per-hop behavior, and
o the particular node implementation mechanisms which realize a
per-hop behavior.
Service provisioning and traffic conditioning policies are
sufficiently decoupled from the forwarding behaviors within the
network interior to permit implementation of a wide variety of
service behaviors, with room for future expansion.
This architecture only provides service differentiation in one
direction of traffic flow and is therefore asymmetric. Development
of a complementary symmetric architecture is a topic of current
research but is outside the scope of this document; see for example
[EXPLICIT].
Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3
lists requirements addressed by this architecture, and Sec. 1.4
provides a brief comparison to other approaches for service
differentiation. Sec. 2 discusses the components of the architecture
Blake, et. al. Informational [Page 3]
RFC 2475 Architecture for Differentiated Services December 1998
in detail. Sec. 3 proposes guidelines for per-hop behavior
specifications. Sec. 4 discusses interoperability issues with nodes
and networks which do not implement differentiated services as
defined in this document and in [DSFIELD]. Sec. 5 discusses issues
with multicast service delivery. Sec. 6 addresses security and
tunnel considerations.
1.2 Terminology
This section gives a general conceptual overview of the terms used in
this document. Some of these terms are more precisely defined in
later sections of this document.
Behavior Aggregate (BA) a DS behavior aggregate.
BA classifier a classifier that selects packets based
only on the contents of the DS field.
Boundary link a link connecting the edge nodes of two
domains.
Classifier an entity which selects packets based on
the content of packet headers according to
defined rules.
DS behavior aggregate a collection of packets with the same DS
codepoint crossing a link in a particular
direction.
DS boundary node a DS node that connects one DS domain to a
node either in another DS domain or in a
domain that is not DS-capable.
DS-capable capable of implementing differentiated
services as described in this architecture;
usually used in reference to a domain
consisting of DS-compliant nodes.
DS codepoint a specific value of the DSCP portion of the
DS field, used to select a PHB.
DS-compliant enabled to support differentiated services
functions and behaviors as defined in
[DSFIELD], this document, and other
differentiated services documents; usually
used in reference to a node or device.
Blake, et. al. Informational [Page 4]
RFC 2475 Architecture for Differentiated Services December 1998
DS domain a DS-capable domain; a contiguous set of
nodes which operate with a common set of
service provisioning policies and PHB
definitions.
DS egress node a DS boundary node in its role in handling
traffic as it leaves a DS domain.
DS ingress node a DS boundary node in its role in handling
traffic as it enters a DS domain.
DS interior node a DS node that is not a DS boundary node.
DS field the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in
conformance with the definition given in
[DSFIELD]. The bits of the DSCP field
encode the DS codepoint, while the
remaining bits are currently unused.
DS node a DS-compliant node.
DS region a set of contiguous DS domains which can
offer differentiated services over paths
across those DS domains.
Downstream DS domain the DS domain downstream of traffic flow on
a boundary link.
Dropper a device that performs dropping.
Dropping the process of discarding packets based on
specified rules; policing.
Legacy node a node which implements IPv4 Precedence as
defined in [RFC791,RFC1812] but which is
otherwise not DS-compliant.
Marker a device that performs marking.
Marking the process of setting the DS codepoint in
a packet based on defined rules; pre-
marking, re-marking.
Mechanism a specific algorithm or operation (e.g.,
queueing discipline) that is implemented in
a node to realize a set of one or more per-
hop behaviors.
Blake, et. al. Informational [Page 5]
RFC 2475 Architecture for Differentiated Services December 1998
Meter a device that performs metering.
Metering the process of measuring the temporal
properties (e.g., rate) of a traffic stream
selected by a classifier. The
instantaneous state of this process may be
used to affect the operation of a marker,
shaper, or dropper, and/or may be used for
accounting and measurement purposes.
Microflow a single instance of an application-to-
application flow of packets which is
identified by source address, source port,
destination address, destination port and
protocol id.
MF Classifier a multi-field (MF) classifier which selects
packets based on the content of some
arbitrary number of header fields;
typically some combination of source
address, destination address, DS field,
protocol ID, source port and destination
port.
Per-Hop-Behavior (PHB) the externally observable forwarding
behavior applied at a DS-compliant node to
a DS behavior aggregate.
PHB group a set of one or more PHBs that can only be
meaningfully specified and implemented
simultaneously, due to a common constraint
applying to all PHBs in the set such as a
queue servicing or queue management policy.
A PHB group provides a service building
block that allows a set of related
forwarding behaviors to be specified
together (e.g., four dropping priorities).
A single PHB is a special case of a PHB
group.
Policing the process of discarding packets (by a
dropper) within a traffic stream in
accordance with the state of a
corresponding meter enforcing a traffic
profile.
Pre-mark to set the DS codepoint of a packet prior
to entry into a downstream DS domain.
Blake, et. al. Informational [Page 6]
RFC 2475 Architecture for Differentiated Services December 1998
Provider DS domain the DS-capable provider of services to a
source domain.
Re-mark to change the DS codepoint of a packet,
usually performed by a marker in accordance
with a TCA.
Service the overall treatment of a defined subset
of a customer's traffic within a DS domain
or end-to-end.
Service Level Agreement a service contract between a customer and a
(SLA) service provider that specifies the
forwarding service a customer should
receive. A customer may be a user
organization (source domain) or another DS
domain (upstream domain). A SLA may
include traffic conditioning rules which
constitute a TCA in whole or in part.
Service Provisioning a policy which defines how traffic
Policy conditioners are configured on DS boundary
nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range
of services.
Shaper a device that performs shaping.
Shaping the process of delaying packets within a
traffic stream to cause it to conform to
some defined traffic profile.
Source domain a domain which contains the node(s)
originating the traffic receiving a
particular service.
Traffic conditioner an entity which performs traffic
conditioning functions and which may
contain meters, markers, droppers, and
shapers. Traffic conditioners are typically
deployed in DS boundary nodes only. A
traffic conditioner may re-mark a traffic
stream or may discard or shape packets to
alter the temporal characteristics of the
stream and bring it into compliance with a
traffic profile.
Blake, et. al. Informational [Page 7]
RFC 2475 Architecture for Differentiated Services December 1998
Traffic conditioning control functions performed to enforce
rules specified in a TCA, including
metering, marking, shaping, and policing.
Traffic Conditioning an agreement specifying classifier rules
Agreement (TCA) and any corresponding traffic profiles and
metering, marking, discarding and/or
shaping rules which are to apply to the
traffic streams selected by the classifier.
A TCA encompasses all of the traffic
conditioning rules explicitly specified
within a SLA along with all of the rules
implicit from the relevant service
requirements and/or from a DS domain's
service provisioning policy.
Traffic profile a description of the temporal properties
of a traffic stream such as rate and burst
size.
Traffic stream an administratively significant set of one
or more microflows which traverse a path
segment. A traffic stream may consist of
the set of active microflows which are
selected by a particular classifier.
Upstream DS domain the DS domain upstream of traffic flow on a
boundary link.
1.3 Requirements
The history of the Internet has been one of continuous growth in the
number of hosts, the number and variety of applications, and the
capacity of the network infrastructure, and this growth is expected
to continue for the foreseeable future. A scalable architecture for
service differentiation must be able to accommodate this continued
growth.
The following requirements were identified and are addressed in this
architecture:
o should accommodate a wide variety of services and provisioning
policies, extending end-to-end or within a particular (set of)
network(s),
o should allow decoupling of the service from the particular
application in use,
Blake, et. al. Informational [Page 8]
RFC 2475 Architecture for Differentiated Services December 1998
o should work with existing applications without the need for
application programming interface changes or host software
modifications (assuming suitable deployment of classifiers,
markers, and other traffic conditioning functions),
o should decouple traffic conditioning and service provisioning
functions from forwarding behaviors implemented within the core
network nodes,
o should not depend on hop-by-hop application signaling,
o should require only a small set of forwarding behaviors whose
implementation complexity does not dominate the cost of a network
device, and which will not introduce bottlenecks for future high-
speed system implementations,
o should avoid per-microflow or per-customer state within core
network nodes,
o should utilize only aggregated classification state within the
network core,
o should permit simple packet classification implementations in core
network nodes (BA classifier),
o should permit reasonable interoperability with non-DS-compliant
network nodes,
o should accommodate incremental deployment.
1.4 Comparisons with Other Approaches
The differentiated services architecture specified in this document
can be contrasted with other existing models of service
differentiation. We classify these alternative models into the
following categories: relative priority marking, service marking,
label switching, Integrated Services/RSVP, and static per-hop
classification.
Examples of the relative priority marking model include IPv4
Precedence marking as defined in [RFC791], 802.5 Token Ring priority
[TR], and the default interpretation of 802.1p traffic classes
[802.1p]. In this model the application, host, or proxy node selects
a relative priority or "precedence" for a packet (e.g., delay or
discard priority), and the network nodes along the transit path apply
the appropriate priority forwarding behavior corresponding to the
priority value within the packet's header. Our architecture can be
considered as a refinement to this model, since we more clearly
Blake, et. al. Informational [Page 9]
RFC 2475 Architecture for Differentiated Services December 1998
specify the role and importance of boundary nodes and traffic
conditioners, and since our per-hop behavior model permits more
general forwarding behaviors than relative delay or discard priority.
An example of a service marking model is IPv4 TOS as defined in
[RFC1349]. In this example each packet is marked with a request for
a "type of service", which may include "minimize delay", "maximize
throughput", "maximize reliability", or "minimize cost". Network
nodes may select routing paths or forwarding behaviors which are
suitably engineered to satisfy the service request. This model is
subtly different from our architecture. Note that we do not describe
the use of the DS field as an input to route selection. The TOS
markings defined in [RFC1349] are very generic and do not span the
range of possible service semantics. Furthermore, the service
request is associated with each individual packet, whereas some
service semantics may depend on the aggregate forwarding behavior of
a sequence of packets. The service marking model does not easily
accommodate growth in the number and range of future services (since
the codepoint space is small) and involves configuration of the
"TOS->forwarding behavior" association in each core network node.
Standardizing service markings implies standardizing service
offerings, which is outside the scope of the IETF. Note that
provisions are made in the allocation of the DS codepoint space to
allow for locally significant codepoints which may be used by a
provider to support service marking semantics [DSFIELD].
Examples of the label switching (or virtual circuit) model include
Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path
forwarding state and traffic management or QoS state is established
for traffic streams on each hop along a network path. Traffic
aggregates of varying granularity are associated with a label
switched path at an ingress node, and packets/cells within each label
switched path are marked with a forwarding label that is used to
lookup the next-hop node, the per-hop forwarding behavior, and the
replacement label at each hop. This model permits finer granularity
resource allocation to traffic streams, since label values are not
globally significant but are only significant on a single link;
therefore resources can be reserved for the aggregate of packets/
cells received on a link with a particular label, and the label
switching semantics govern the next-hop selection, allowing a traffic
stream to follow a specially engineered path through the network.
This improved granularity comes at the cost of additional management
and configuration requirements to establish and maintain the label
switched paths. In addition, the amount of forwarding state
maintained at each node scales in proportion to the number of edge
nodes of the network in the best case (assuming multipoint-to-point
Blake, et. al. Informational [Page 10]
RFC 2475 Architecture for Differentiated Services December 1998
label switched paths), and it scales in proportion with the square of
the number of edge nodes in the worst case, when edge-edge label
switched paths with provisioned resources are employed.
The Integrated Services/RSVP model relies upon traditional datagram
forwarding in the default case, but allows sources and receivers to
exchange signaling messages which establish additional packet
classification and forwarding state on each node along the path
between them [RFC1633, RSVP]. In the absence of state aggregation,
the amount of state on each node scales in proportion to the number
of concurrent reservations, which can be potentially large on high-
speed links. This model also requires application support for the
RSVP signaling protocol. Differentiated services mechanisms can be
utilized to aggregate Integrated Services/RSVP state in the core of
the network [Bernet].
A variant of the Integrated Services/RSVP model eliminates the
requirement for hop-by-hop signaling by utilizing only "static"
classification and forwarding policies which are implemented in each
node along a network path. These policies are updated on
administrative timescales and not in response to the instantaneous
mix of microflows active in the network. The state requirements for
this variant are potentially worse than those encountered when RSVP
is used, especially in backbone nodes, since the number of static
policies that might be applicable at a node over time may be larger
than the number of active sender-receiver sessions that might have
installed reservation state on a node. Although the support of large
numbers of classifier rules and forwarding policies may be
computationally feasible, the management burden associated with
installing and maintaining these rules on each node within a backbone
network which might be traversed by a traffic stream is substantial.
Although we contrast our architecture with these alternative models
of service differentiation, it should be noted that links and nodes
employing these techniques may be utilized to extend differentiated
services behaviors and semantics across a layer-2 switched
infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones)
interconnecting DS nodes, and in the case of MPLS may be used as an
alternative intra-domain implementation technology. The constraints
imposed by the use of a specific link-layer technology in particular
regions of a DS domain (or in a network providing access to DS
domains) may imply the differentiation of traffic on a coarser grain
basis. Depending on the mapping of PHBs to different link-layer
services and the way in which packets are scheduled over a restricted
set of priority classes (or virtual circuits of different category
and capacity), all or a subset of the PHBs in use may be supportable
(or may be indistinguishable).
Blake, et. al. Informational [Page 11]
RFC 2475 Architecture for Differentiated Services December 1998
2. Differentiated Services Architectural Model
The differentiated services architecture is based on a simple model
where traffic entering a network is classified and possibly
conditioned at the boundaries of the network, and assigned to
different behavior aggregates. Each behavior aggregate is identified
by a single DS codepoint. Within the core of the network, packets
are forwarded according to the per-hop behavior associated with the
DS codepoint. In this section, we discuss the key components within
a differentiated services region, traffic classification and
conditioning functions, and how differentiated services are achieved
through the combination of traffic conditioning and PHB-based
forwarding.
2.1 Differentiated Services Domain
A DS domain is a contiguous set of DS nodes which operate with a
common service provisioning policy and set of PHB groups implemented
on each node. A DS domain has a well-defined boundary consisting of
DS boundary nodes which classify and possibly condition ingress
traffic to ensure that packets which transit the domain are
appropriately marked to select a PHB from one of the PHB groups
supported within the domain. Nodes within the DS domain select the
forwarding behavior for packets based on their DS codepoint, mapping
that value to one of the supported PHBs using either the recommended
codepoint->PHB mapping or a locally customized mapping [DSFIELD].
Inclusion of non-DS-compliant nodes within a DS domain may result in
unpredictable performance and may impede the ability to satisfy
service level agreements (SLAs).
A DS domain normally consists of one or more networks under the same
administration; for example, an organization's intranet or an ISP.
The administration of the domain is responsible for ensuring that
adequate resources are provisioned and/or reserved to support the
SLAs offered by the domain.
2.1.1 DS Boundary Nodes and Interior Nodes
A DS domain consists of DS boundary nodes and DS interior nodes. DS
boundary nodes interconnect the DS domain to other DS or non-DS-
capable domains, whilst DS interior nodes only connect to other DS
interior or boundary nodes within the same DS domain.
Both DS boundary nodes and interior nodes must be able to apply the
appropriate PHB to packets based on the DS codepoint; otherwise
unpredictable behavior may result. In addition, DS boundary nodes
may be required to perform traffic conditioning functions as defined
by a traffic conditioning agreement (TCA) between their DS domain and
Blake, et. al. Informational [Page 12]
RFC 2475 Architecture for Differentiated Services December 1998
the peering domain which they connect to (see Sec. 2.3.3).
Interior nodes may be able to perform limited traffic conditioning
functions such as DS codepoint re-marking. Interior nodes which
implement more complex classification and traffic conditioning
functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
A host in a network containing a DS domain may act as a DS boundary
node for traffic from applications running on that host; we therefore
say that the host is within the DS domain. If a host does not act as
a boundary node, then the DS node topologically closest to that host
acts as the DS boundary node for that host's traffic.
2.1.2 DS Ingress Node and Egress Node
DS boundary nodes act both as a DS ingress node and as a DS egress
node for different directions of traffic. Traffic enters a DS domain
at a DS ingress node and leaves a DS domain at a DS egress node. A
DS ingress node is responsible for ensuring that the traffic entering
the DS domain conforms to any TCA between it and the other domain to
which the ingress node is connected. A DS egress node may perform
traffic conditioning functions on traffic forwarded to a directly
connected peering domain, depending on the details of the TCA between
the two domains. Note that a DS boundary node may act as a DS
interior node for some set of interfaces.
2.2 Differentiated Services Region
Last edited by ncwdavid on Mon Oct 08, 2007 3:19 pm; edited 3 times in total
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document defines an architecture for implementing scalable
service differentiation in the Internet. This architecture achieves
scalability by aggregating traffic classification state which is
conveyed by means of IP-layer packet marking using the DS field
[DSFIELD]. Packets are classified and marked to receive a particular
per-hop forwarding behavior on nodes along their path. Sophisticated
classification, marking, policing, and shaping operations need only
be implemented at network boundaries or hosts. Network resources are
allocated to traffic streams by service provisioning policies which
govern how traffic is marked and conditioned upon entry to a
differentiated services-capable network, and how that traffic is
forwarded within that network. A wide variety of services can be
implemented on top of these building blocks.
Blake, et. al. Informational [Page 1]
RFC 2475 Architecture for Differentiated Services December 1998
Table of Contents
1. Introduction ................................................. 2
1.1 Overview ................................................. 2
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 12
2.1 Differentiated Services Domain ............................ 12
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 13
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 14
2.3.1 Classifiers ........................................... 14
2.3.2 Traffic Profiles ...................................... 15
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 16
2.3.3.2 Markers ........................................... 16
2.3.3.3 Shapers ........................................... 17
2.3.3.4 Droppers .......................................... 17
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17
2.3.4.1 Within the Source Domain .......................... 17
2.3.4.2 At the Boundary of a DS Domain .................... 18
2.3.4.3 In non-DS-Capable Domains ......................... 18
2.3.4.4 In Interior DS Nodes .............................. 19
2.4 Per-Hop Behaviors ......................................... 19
2.5 Network Resource Allocation ............................... 20
3. Per-Hop Behavior Specification Guidelines .................... 21
4. Interoperability with Non-Differentiated Services-Compliant
Nodes ........................................................ 25
5. Multicast Considerations ..................................... 26
6. Security and Tunneling Considerations ........................ 27
6.1 Theft and Denial of Service ............................... 28
6.2 IPsec and Tunneling Interactions .......................... 30
6.3 Auditing .................................................. 32
7. Acknowledgements ............................................. 32
8. References ................................................... 33
Authors' Addresses ............................................... 34
Full Copyright Statement ......................................... 36
1. Introduction
1.1 Overview
This document defines an architecture for implementing scalable
service differentiation in the Internet. A "Service" defines some
significant characteristics of packet transmission in one direction
across a set of one or more paths within a network. These
Blake, et. al. Informational [Page 2]
RFC 2475 Architecture for Differentiated Services December 1998
characteristics may be specified in quantitative or statistical terms
of throughput, delay, jitter, and/or loss, or may otherwise be
specified in terms of some relative priority of access to network
resources. Service differentiation is desired to accommodate
heterogeneous application requirements and user expectations, and to
permit differentiated pricing of Internet service.
This architecture is composed of a number of functional elements
implemented in network nodes, including a small set of per-hop
forwarding behaviors, packet classification functions, and traffic
conditioning functions including metering, marking, shaping, and
policing. This architecture achieves scalability by implementing
complex classification and conditioning functions only at network
boundary nodes, and by applying per-hop behaviors to aggregates of
traffic which have been appropriately marked using the DS field in
the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to
permit a reasonably granular means of allocating buffer and bandwidth
resources at each node among competing traffic streams. Per-
application flow or per-customer forwarding state need not be
maintained within the core of the network. A distinction is
maintained between:
o the service provided to a traffic aggregate,
o the conditioning functions and per-hop behaviors used to realize
services,
o the DS field value (DS codepoint) used to mark packets to select a
per-hop behavior, and
o the particular node implementation mechanisms which realize a
per-hop behavior.
Service provisioning and traffic conditioning policies are
sufficiently decoupled from the forwarding behaviors within the
network interior to permit implementation of a wide variety of
service behaviors, with room for future expansion.
This architecture only provides service differentiation in one
direction of traffic flow and is therefore asymmetric. Development
of a complementary symmetric architecture is a topic of current
research but is outside the scope of this document; see for example
[EXPLICIT].
Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3
lists requirements addressed by this architecture, and Sec. 1.4
provides a brief comparison to other approaches for service
differentiation. Sec. 2 discusses the components of the architecture
Blake, et. al. Informational [Page 3]
RFC 2475 Architecture for Differentiated Services December 1998
in detail. Sec. 3 proposes guidelines for per-hop behavior
specifications. Sec. 4 discusses interoperability issues with nodes
and networks which do not implement differentiated services as
defined in this document and in [DSFIELD]. Sec. 5 discusses issues
with multicast service delivery. Sec. 6 addresses security and
tunnel considerations.
1.2 Terminology
This section gives a general conceptual overview of the terms used in
this document. Some of these terms are more precisely defined in
later sections of this document.
Behavior Aggregate (BA) a DS behavior aggregate.
BA classifier a classifier that selects packets based
only on the contents of the DS field.
Boundary link a link connecting the edge nodes of two
domains.
Classifier an entity which selects packets based on
the content of packet headers according to
defined rules.
DS behavior aggregate a collection of packets with the same DS
codepoint crossing a link in a particular
direction.
DS boundary node a DS node that connects one DS domain to a
node either in another DS domain or in a
domain that is not DS-capable.
DS-capable capable of implementing differentiated
services as described in this architecture;
usually used in reference to a domain
consisting of DS-compliant nodes.
DS codepoint a specific value of the DSCP portion of the
DS field, used to select a PHB.
DS-compliant enabled to support differentiated services
functions and behaviors as defined in
[DSFIELD], this document, and other
differentiated services documents; usually
used in reference to a node or device.
Blake, et. al. Informational [Page 4]
RFC 2475 Architecture for Differentiated Services December 1998
DS domain a DS-capable domain; a contiguous set of
nodes which operate with a common set of
service provisioning policies and PHB
definitions.
DS egress node a DS boundary node in its role in handling
traffic as it leaves a DS domain.
DS ingress node a DS boundary node in its role in handling
traffic as it enters a DS domain.
DS interior node a DS node that is not a DS boundary node.
DS field the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in
conformance with the definition given in
[DSFIELD]. The bits of the DSCP field
encode the DS codepoint, while the
remaining bits are currently unused.
DS node a DS-compliant node.
DS region a set of contiguous DS domains which can
offer differentiated services over paths
across those DS domains.
Downstream DS domain the DS domain downstream of traffic flow on
a boundary link.
Dropper a device that performs dropping.
Dropping the process of discarding packets based on
specified rules; policing.
Legacy node a node which implements IPv4 Precedence as
defined in [RFC791,RFC1812] but which is
otherwise not DS-compliant.
Marker a device that performs marking.
Marking the process of setting the DS codepoint in
a packet based on defined rules; pre-
marking, re-marking.
Mechanism a specific algorithm or operation (e.g.,
queueing discipline) that is implemented in
a node to realize a set of one or more per-
hop behaviors.
Blake, et. al. Informational [Page 5]
RFC 2475 Architecture for Differentiated Services December 1998
Meter a device that performs metering.
Metering the process of measuring the temporal
properties (e.g., rate) of a traffic stream
selected by a classifier. The
instantaneous state of this process may be
used to affect the operation of a marker,
shaper, or dropper, and/or may be used for
accounting and measurement purposes.
Microflow a single instance of an application-to-
application flow of packets which is
identified by source address, source port,
destination address, destination port and
protocol id.
MF Classifier a multi-field (MF) classifier which selects
packets based on the content of some
arbitrary number of header fields;
typically some combination of source
address, destination address, DS field,
protocol ID, source port and destination
port.
Per-Hop-Behavior (PHB) the externally observable forwarding
behavior applied at a DS-compliant node to
a DS behavior aggregate.
PHB group a set of one or more PHBs that can only be
meaningfully specified and implemented
simultaneously, due to a common constraint
applying to all PHBs in the set such as a
queue servicing or queue management policy.
A PHB group provides a service building
block that allows a set of related
forwarding behaviors to be specified
together (e.g., four dropping priorities).
A single PHB is a special case of a PHB
group.
Policing the process of discarding packets (by a
dropper) within a traffic stream in
accordance with the state of a
corresponding meter enforcing a traffic
profile.
Pre-mark to set the DS codepoint of a packet prior
to entry into a downstream DS domain.
Blake, et. al. Informational [Page 6]
RFC 2475 Architecture for Differentiated Services December 1998
Provider DS domain the DS-capable provider of services to a
source domain.
Re-mark to change the DS codepoint of a packet,
usually performed by a marker in accordance
with a TCA.
Service the overall treatment of a defined subset
of a customer's traffic within a DS domain
or end-to-end.
Service Level Agreement a service contract between a customer and a
(SLA) service provider that specifies the
forwarding service a customer should
receive. A customer may be a user
organization (source domain) or another DS
domain (upstream domain). A SLA may
include traffic conditioning rules which
constitute a TCA in whole or in part.
Service Provisioning a policy which defines how traffic
Policy conditioners are configured on DS boundary
nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range
of services.
Shaper a device that performs shaping.
Shaping the process of delaying packets within a
traffic stream to cause it to conform to
some defined traffic profile.
Source domain a domain which contains the node(s)
originating the traffic receiving a
particular service.
Traffic conditioner an entity which performs traffic
conditioning functions and which may
contain meters, markers, droppers, and
shapers. Traffic conditioners are typically
deployed in DS boundary nodes only. A
traffic conditioner may re-mark a traffic
stream or may discard or shape packets to
alter the temporal characteristics of the
stream and bring it into compliance with a
traffic profile.
Blake, et. al. Informational [Page 7]
RFC 2475 Architecture for Differentiated Services December 1998
Traffic conditioning control functions performed to enforce
rules specified in a TCA, including
metering, marking, shaping, and policing.
Traffic Conditioning an agreement specifying classifier rules
Agreement (TCA) and any corresponding traffic profiles and
metering, marking, discarding and/or
shaping rules which are to apply to the
traffic streams selected by the classifier.
A TCA encompasses all of the traffic
conditioning rules explicitly specified
within a SLA along with all of the rules
implicit from the relevant service
requirements and/or from a DS domain's
service provisioning policy.
Traffic profile a description of the temporal properties
of a traffic stream such as rate and burst
size.
Traffic stream an administratively significant set of one
or more microflows which traverse a path
segment. A traffic stream may consist of
the set of active microflows which are
selected by a particular classifier.
Upstream DS domain the DS domain upstream of traffic flow on a
boundary link.
1.3 Requirements
The history of the Internet has been one of continuous growth in the
number of hosts, the number and variety of applications, and the
capacity of the network infrastructure, and this growth is expected
to continue for the foreseeable future. A scalable architecture for
service differentiation must be able to accommodate this continued
growth.
The following requirements were identified and are addressed in this
architecture:
o should accommodate a wide variety of services and provisioning
policies, extending end-to-end or within a particular (set of)
network(s),
o should allow decoupling of the service from the particular
application in use,
Blake, et. al. Informational [Page 8]
RFC 2475 Architecture for Differentiated Services December 1998
o should work with existing applications without the need for
application programming interface changes or host software
modifications (assuming suitable deployment of classifiers,
markers, and other traffic conditioning functions),
o should decouple traffic conditioning and service provisioning
functions from forwarding behaviors implemented within the core
network nodes,
o should not depend on hop-by-hop application signaling,
o should require only a small set of forwarding behaviors whose
implementation complexity does not dominate the cost of a network
device, and which will not introduce bottlenecks for future high-
speed system implementations,
o should avoid per-microflow or per-customer state within core
network nodes,
o should utilize only aggregated classification state within the
network core,
o should permit simple packet classification implementations in core
network nodes (BA classifier),
o should permit reasonable interoperability with non-DS-compliant
network nodes,
o should accommodate incremental deployment.
1.4 Comparisons with Other Approaches
The differentiated services architecture specified in this document
can be contrasted with other existing models of service
differentiation. We classify these alternative models into the
following categories: relative priority marking, service marking,
label switching, Integrated Services/RSVP, and static per-hop
classification.
Examples of the relative priority marking model include IPv4
Precedence marking as defined in [RFC791], 802.5 Token Ring priority
[TR], and the default interpretation of 802.1p traffic classes
[802.1p]. In this model the application, host, or proxy node selects
a relative priority or "precedence" for a packet (e.g., delay or
discard priority), and the network nodes along the transit path apply
the appropriate priority forwarding behavior corresponding to the
priority value within the packet's header. Our architecture can be
considered as a refinement to this model, since we more clearly
Blake, et. al. Informational [Page 9]
RFC 2475 Architecture for Differentiated Services December 1998
specify the role and importance of boundary nodes and traffic
conditioners, and since our per-hop behavior model permits more
general forwarding behaviors than relative delay or discard priority.
An example of a service marking model is IPv4 TOS as defined in
[RFC1349]. In this example each packet is marked with a request for
a "type of service", which may include "minimize delay", "maximize
throughput", "maximize reliability", or "minimize cost". Network
nodes may select routing paths or forwarding behaviors which are
suitably engineered to satisfy the service request. This model is
subtly different from our architecture. Note that we do not describe
the use of the DS field as an input to route selection. The TOS
markings defined in [RFC1349] are very generic and do not span the
range of possible service semantics. Furthermore, the service
request is associated with each individual packet, whereas some
service semantics may depend on the aggregate forwarding behavior of
a sequence of packets. The service marking model does not easily
accommodate growth in the number and range of future services (since
the codepoint space is small) and involves configuration of the
"TOS->forwarding behavior" association in each core network node.
Standardizing service markings implies standardizing service
offerings, which is outside the scope of the IETF. Note that
provisions are made in the allocation of the DS codepoint space to
allow for locally significant codepoints which may be used by a
provider to support service marking semantics [DSFIELD].
Examples of the label switching (or virtual circuit) model include
Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path
forwarding state and traffic management or QoS state is established
for traffic streams on each hop along a network path. Traffic
aggregates of varying granularity are associated with a label
switched path at an ingress node, and packets/cells within each label
switched path are marked with a forwarding label that is used to
lookup the next-hop node, the per-hop forwarding behavior, and the
replacement label at each hop. This model permits finer granularity
resource allocation to traffic streams, since label values are not
globally significant but are only significant on a single link;
therefore resources can be reserved for the aggregate of packets/
cells received on a link with a particular label, and the label
switching semantics govern the next-hop selection, allowing a traffic
stream to follow a specially engineered path through the network.
This improved granularity comes at the cost of additional management
and configuration requirements to establish and maintain the label
switched paths. In addition, the amount of forwarding state
maintained at each node scales in proportion to the number of edge
nodes of the network in the best case (assuming multipoint-to-point
Blake, et. al. Informational [Page 10]
RFC 2475 Architecture for Differentiated Services December 1998
label switched paths), and it scales in proportion with the square of
the number of edge nodes in the worst case, when edge-edge label
switched paths with provisioned resources are employed.
The Integrated Services/RSVP model relies upon traditional datagram
forwarding in the default case, but allows sources and receivers to
exchange signaling messages which establish additional packet
classification and forwarding state on each node along the path
between them [RFC1633, RSVP]. In the absence of state aggregation,
the amount of state on each node scales in proportion to the number
of concurrent reservations, which can be potentially large on high-
speed links. This model also requires application support for the
RSVP signaling protocol. Differentiated services mechanisms can be
utilized to aggregate Integrated Services/RSVP state in the core of
the network [Bernet].
A variant of the Integrated Services/RSVP model eliminates the
requirement for hop-by-hop signaling by utilizing only "static"
classification and forwarding policies which are implemented in each
node along a network path. These policies are updated on
administrative timescales and not in response to the instantaneous
mix of microflows active in the network. The state requirements for
this variant are potentially worse than those encountered when RSVP
is used, especially in backbone nodes, since the number of static
policies that might be applicable at a node over time may be larger
than the number of active sender-receiver sessions that might have
installed reservation state on a node. Although the support of large
numbers of classifier rules and forwarding policies may be
computationally feasible, the management burden associated with
installing and maintaining these rules on each node within a backbone
network which might be traversed by a traffic stream is substantial.
Although we contrast our architecture with these alternative models
of service differentiation, it should be noted that links and nodes
employing these techniques may be utilized to extend differentiated
services behaviors and semantics across a layer-2 switched
infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones)
interconnecting DS nodes, and in the case of MPLS may be used as an
alternative intra-domain implementation technology. The constraints
imposed by the use of a specific link-layer technology in particular
regions of a DS domain (or in a network providing access to DS
domains) may imply the differentiation of traffic on a coarser grain
basis. Depending on the mapping of PHBs to different link-layer
services and the way in which packets are scheduled over a restricted
set of priority classes (or virtual circuits of different category
and capacity), all or a subset of the PHBs in use may be supportable
(or may be indistinguishable).
Blake, et. al. Informational [Page 11]
RFC 2475 Architecture for Differentiated Services December 1998
2. Differentiated Services Architectural Model
The differentiated services architecture is based on a simple model
where traffic entering a network is classified and possibly
conditioned at the boundaries of the network, and assigned to
different behavior aggregates. Each behavior aggregate is identified
by a single DS codepoint. Within the core of the network, packets
are forwarded according to the per-hop behavior associated with the
DS codepoint. In this section, we discuss the key components within
a differentiated services region, traffic classification and
conditioning functions, and how differentiated services are achieved
through the combination of traffic conditioning and PHB-based
forwarding.
2.1 Differentiated Services Domain
A DS domain is a contiguous set of DS nodes which operate with a
common service provisioning policy and set of PHB groups implemented
on each node. A DS domain has a well-defined boundary consisting of
DS boundary nodes which classify and possibly condition ingress
traffic to ensure that packets which transit the domain are
appropriately marked to select a PHB from one of the PHB groups
supported within the domain. Nodes within the DS domain select the
forwarding behavior for packets based on their DS codepoint, mapping
that value to one of the supported PHBs using either the recommended
codepoint->PHB mapping or a locally customized mapping [DSFIELD].
Inclusion of non-DS-compliant nodes within a DS domain may result in
unpredictable performance and may impede the ability to satisfy
service level agreements (SLAs).
A DS domain normally consists of one or more networks under the same
administration; for example, an organization's intranet or an ISP.
The administration of the domain is responsible for ensuring that
adequate resources are provisioned and/or reserved to support the
SLAs offered by the domain.
2.1.1 DS Boundary Nodes and Interior Nodes
A DS domain consists of DS boundary nodes and DS interior nodes. DS
boundary nodes interconnect the DS domain to other DS or non-DS-
capable domains, whilst DS interior nodes only connect to other DS
interior or boundary nodes within the same DS domain.
Both DS boundary nodes and interior nodes must be able to apply the
appropriate PHB to packets based on the DS codepoint; otherwise
unpredictable behavior may result. In addition, DS boundary nodes
may be required to perform traffic conditioning functions as defined
by a traffic conditioning agreement (TCA) between their DS domain and
Blake, et. al. Informational [Page 12]
RFC 2475 Architecture for Differentiated Services December 1998
the peering domain which they connect to (see Sec. 2.3.3).
Interior nodes may be able to perform limited traffic conditioning
functions such as DS codepoint re-marking. Interior nodes which
implement more complex classification and traffic conditioning
functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
A host in a network containing a DS domain may act as a DS boundary
node for traffic from applications running on that host; we therefore
say that the host is within the DS domain. If a host does not act as
a boundary node, then the DS node topologically closest to that host
acts as the DS boundary node for that host's traffic.
2.1.2 DS Ingress Node and Egress Node
DS boundary nodes act both as a DS ingress node and as a DS egress
node for different directions of traffic. Traffic enters a DS domain
at a DS ingress node and leaves a DS domain at a DS egress node. A
DS ingress node is responsible for ensuring that the traffic entering
the DS domain conforms to any TCA between it and the other domain to
which the ingress node is connected. A DS egress node may perform
traffic conditioning functions on traffic forwarded to a directly
connected peering domain, depending on the details of the TCA between
the two domains. Note that a DS boundary node may act as a DS
interior node for some set of interfaces.
2.2 Differentiated Services Region
Last edited by ncwdavid on Mon Oct 08, 2007 3:19 pm; edited 3 times in total
Usually plain sites but actually a bit of both is quite good. Flash sites are a pain to edit as well I find, if you actually run them. Although an almost 3rd generation flash design is pretty suitible on places if you can afford them 
Some flash sites are just amazing and are way superior to any plain site (for instance, quake4game.com). Some less attractive websites that use flash can get annoying, especially when they use flash when it's completely unnecessary. Also, sometimes when switching between pages and waiting for a big flash file to load or hearing the same sound when clicking between pages can get annoying. Some plain sites can be very attractive too and are a lot of the time much easier to navigate around.
In my opinion that flash sites are just huge for my connection. Plus I have Windows '98 and Internet Explorer 6, and all flash animations are bugging as crazy!
So that's why I prefer simple images or HTML. You can do same things with flash and without it just with help of images. I don't see no reason to use Flash technology... except for creation of funny cartoons=))
So that's why I prefer simple images or HTML. You can do same things with flash and without it just with help of images. I don't see no reason to use Flash technology... except for creation of funny cartoons=))
| Macko112 wrote: |
| Some flash sites are just amazing and are way superior to any plain site (for instance, quake4game.com). Some less attractive websites that use flash can get annoying, especially when they use flash when it's completely unnecessary. Also, sometimes when switching between pages and waiting for a big flash file to load or hearing the same sound when clicking between pages can get annoying. Some plain sites can be very attractive too and are a lot of the time much easier to navigate around. |
I see your point but i don't know really its just always appealed to me maybe because im wierd
I prefer flash sites. They are just cooler and more... exciting. I think it adds a little something extra to the website. 
I just like to get my info and get on with it. Flash just gets in the way, and doesn't work all the time. I hate having to download something else just to view a web page.
| sky217 wrote: |
| I just like to get my info and get on with it. Flash just gets in the way, and doesn't work all the time. I hate having to download something else just to view a web page. |
Couldn't have said it better myself.
If it's not an animation telling a story of some sort for entertainment, or demostrating the uses of a product where text would be subpar, then I don't want flash.
I like flash sites depending on what the site is about. Some are suitable to use flash but some really aren't. But some of the time it just takes too long for the site to load up.
You all have good points but i think a mix is great like a plain site with like animated bits on it is really cool.
I prefer plain. I think flash is the worst thing ever. It is slow to browse flash-page, you can't open links in new tabs, they can download the page for minutes and usually there are sound effects too, and sounds on webpage is never a good thing. And macromedia flash player's installation sucks.
Plain. That is it.
Plain. That is it.
depends on your target audience. If they need flashy stuff then flash is the way to go different browsers and OS's make that sort of stuff to do in JS a nightmare (thanks, Microsoft!) - however a site shouldn't be made to use the most recent versions of flash - nothing more off-putting than going to a site and being told that your flash browser is out of date and youve just downloaded it a week ago.
For me HTML any time anywhere - plain old HTML can make perfectly good presentation and its quicker.
For me HTML any time anywhere - plain old HTML can make perfectly good presentation and its quicker.
Never really liked flash sites too much - always annoyed me to no end if there was some text in the page I wanted to copy+paste, or if it wouldn't let me right-click a download link / new window link for options.
Well heres a whole lot more answers: http://www.frihost.com/forums/vt-23269.html
| reddishblue wrote: |
| Well heres a whole lot more answers: http://www.frihost.com/forums/vt-23269.html |
Very true reddishblue, but that particular topic deals with "what is flash for", not "which do you prefer".
I personally love flash/shockwave, all of my sites are done in it, but it does have it's initial drawbacks. Yes it is cool and looks nice, but as far as SEO goes it really sucks.
Search engines do not read flash and only see the index page and do not spider the rest of your site unless you take appropriate measures, so as far as that goes....it's good for specialized or personal sites, but not so good for getting yourself listed with the search engines out there.
There's flash sites, there's plain sites, and then there's business websites.
Flash sites are for entertainment, while plain sites are for information.
Combining the two creates a business website, with annoying advertisements constantly looping, telling you to buy said product in ad.
I use plain sites most of the time, so I suppose I prefer them. After all, J.K. Rowling's blog can only hold your attention for so long.
Flash sites are for entertainment, while plain sites are for information.
Combining the two creates a business website, with annoying advertisements constantly looping, telling you to buy said product in ad.
I use plain sites most of the time, so I suppose I prefer them. After all, J.K. Rowling's blog can only hold your attention for so long.
I prefer plain websites over flash. For these following reasons:
1. Flash doesn't work everywhere.
2. Printing in flash is wildly difficult.
3. There is now way to bookmark a sub pages of a full flash site.
4. It does not work in most alternative devices.
5. It requires proprietary plug-in.
6. Flash is not indexable in search engines.
I love flash so much but for a site to love by many you've got to think twice. It is better to have a pure html website.
1. Flash doesn't work everywhere.
2. Printing in flash is wildly difficult.
3. There is now way to bookmark a sub pages of a full flash site.
4. It does not work in most alternative devices.
5. It requires proprietary plug-in.
6. Flash is not indexable in search engines.
I love flash so much but for a site to love by many you've got to think twice. It is better to have a pure html website.
I prefer 'plain' websites. Websites made with flash are just too... flashy and distracting. Often I have to think and look everywhere before I know how to use the navigation properly, haha. Plain websites are easier to navigate through. Well, more often anyway.
I feel that although Flash websites look really good, they rarely contain lots of information that is actually useful to the reader. One good example is the Harry Potter website, which is rarely updated and it takes forever to load something that is completely pointless, like the 'Marauder's Map' when you can just use the uber-simple 'Menu' on the left of the page which actually links to everywhere in the site.
Hmm... Yeah, I've seemed to notice that too. I think it's because the flash websites take a lot of space and theres not much more room left for information. What would be a good Idea for flash sites is to post all the information in a... well maybe a wiki or on their forum. 
You can easily get more content on a plain site.
But with flash it can be beautiful!
So use both !
I usually make the header of the website with flash.
But with flash it can be beautiful!
So use both !
I usually make the header of the website with flash.
I prefer both sites, imagine yourself that google turned into a flash site, just horrible. Some sites look very cool in flash, however those sites are more "have fun" sites. So it reallt depends.
Greats,
Greats,
| Zenireth wrote: |
| What one do you prefer? sorry im curius, i prefer Flash |
i like flash sites... but my internet connection doesn't let me load them fast
I like both. 
The plus with flash you can make pretty cool web sites,
but the minus is that you have to install flash player (no problem usually, but on public computers...) and that it can take some time to load for people with low bandwidth.
For plain sites, I am a fan of using <table> with css to make the layout
The plus with flash you can make pretty cool web sites,
but the minus is that you have to install flash player (no problem usually, but on public computers...) and that it can take some time to load for people with low bandwidth.
For plain sites, I am a fan of using <table> with css to make the layout
| Zenireth wrote: |
| What one do you prefer? sorry im curius, i prefer Flash |
Yeah, I think it really depends on what kind of website it is. If it is some type of corporate site that wants to attract potential customers and whatnot, then sure - use a flashy Flash site. But if you're, for instance, a game codes and FAQs site, I'd rather navigate through a nicely-laid-out HTML site. And my sites for instance, I don't need a flash site because my site isn't what I want users to be attracted to - it's the videos. Which oddly enough are soon to be in flash format....
As I stated previously, flash sites do have thier drawbacks, but one of the I won't endorse is loading time. Everyone wants to upgrade the pc's RAM/CPU/CD reader burner/DVD capabilities...what about upgrading your internet connection?
Any chain is only as strong as it's weakest link, in this particular case it's the Internet/connectivity speed that is weak.
Flash CAN work for all sites, it just takes a bit more thinking and coding.
However, on a profit ingrained site, the flash can be extremely annoying and quite possibly distract and push users/members/clients away.
*NOTE* Maybe this topic belongs in the WebDesign Forum. If the topic continues....it will be moved.
Any chain is only as strong as it's weakest link, in this particular case it's the Internet/connectivity speed that is weak.
Flash CAN work for all sites, it just takes a bit more thinking and coding.
However, on a profit ingrained site, the flash can be extremely annoying and quite possibly distract and push users/members/clients away.
*NOTE* Maybe this topic belongs in the WebDesign Forum. If the topic continues....it will be moved.
I prefer plain sites.
I know flash sites look very nice but sometimes it takes long time to load the page. And some errors happened to flash sites.
I know flash sites look very nice but sometimes it takes long time to load the page. And some errors happened to flash sites.
Topic has been moved to the appropriate forum.
I prefer flash since I don't know what plain is 
"Plain are websites writen in stricly HTML (maybe some Javascript added), but do not have the added motion not graphics that be easliy added via Flash.
It is also the best place (leaning curve involved) to learn how to build a webpage. Most webpages writen in HTML are considered "static", which they don't change unless you change they yourself.
There are a great many tutorials available on how to learn this....if you seek help on this matter, there are a great members here would be more than happy to help you.
It is also the best place (leaning curve involved) to learn how to build a webpage. Most webpages writen in HTML are considered "static", which they don't change unless you change they yourself.
There are a great many tutorials available on how to learn this....if you seek help on this matter, there are a great members here would be more than happy to help you.
I hate flash and I do not recommend using them except when it is really needed.
I like flash site,it is often very cool.but I can not built one because I am not good at making flash.
| bangala wrote: |
| I hate flash and I do not recommend using them except when it is really needed. |
They certainly serve a very useful purpose, I don't understand your alleged hatred of what WILL be a seriously used technology in the very near future.
If it's the download time of the .swf files you hate....get a faster connection.
No matter how any of us feel about it...we are going to have to deal with it.
| Zenireth wrote: |
| What one do you prefer? sorry im curius, i prefer Flash |
I prefer non-flash sites. I find that they load quicker, do more (with the help of PHP), normally can run in any browser, can look better, get the point out much faster.
Though I prefer Flash for single player games and presentations.
Last edited by pyapplico on Sun Apr 15, 2007 3:15 am; edited 1 time in total
Flash can be used for things that HTML/CSS cannot do. In those cases (very few, actually), I prefer Flash. Examples can be cool presentations, games etc. The Playstation Singstar site would be a lot more boring if they had made it in plain HTML/CSS (But they SHOULD have an alternative HTML/CSS-version).
Mostly, on webpages I visit daily and "use", I prefer usability. Plain HTML/CSS (they can still look great!). The day my bank switches to Flash, I will switch bank! Bandwidth is no problem for me.
One of the problems with flash, is the people making the flash-sites. Some make the sites in one big swf-file (its like the whole site is an interactive image), instead of going from address to address. If you should be so unlucky to hit refresh in the middle of a quiz or a registrationform, you have to start all over again from the frontpage, and work your way through all the mystery meat navigation you often find on those sites. You cannot bookmark a section you like. And on some flash-sites, if you want to copy the visiting-address or phone number to that cool firm you wanted to contact, you cannot copy the text, but manually write it down! Also some flash-"designers" make flash-sites that has nothing extra than a ordinary HTML/CSS-site unless unusability. Thats as stupid as buying an x-box just to play audio-CDs... (Reminder: the last paragraph was about skill-less flash-designers, not skill-full flash-designers)
Mostly, on webpages I visit daily and "use", I prefer usability. Plain HTML/CSS (they can still look great!). The day my bank switches to Flash, I will switch bank! Bandwidth is no problem for me.
One of the problems with flash, is the people making the flash-sites. Some make the sites in one big swf-file (its like the whole site is an interactive image), instead of going from address to address. If you should be so unlucky to hit refresh in the middle of a quiz or a registrationform, you have to start all over again from the frontpage, and work your way through all the mystery meat navigation you often find on those sites. You cannot bookmark a section you like. And on some flash-sites, if you want to copy the visiting-address or phone number to that cool firm you wanted to contact, you cannot copy the text, but manually write it down! Also some flash-"designers" make flash-sites that has nothing extra than a ordinary HTML/CSS-site unless unusability. Thats as stupid as buying an x-box just to play audio-CDs... (Reminder: the last paragraph was about skill-less flash-designers, not skill-full flash-designers)
one sentence , I feel plain sites with PHP as more powerful.
Flash needs support for player and too much depends on thhe
client side.
Flash needs support for player and too much depends on thhe
client side.
| pspcoder05 wrote: |
| one sentence , I feel plain sites with PHP as more powerful.
Flash needs support for player and too much depends on thhe client side. |
And what of the serverside issues involved with the installation and configuration of a Pre-Hypertext Processor (PHP)? Do you have even a clue what cpu usage is required to make PHP work??
Is everything supposed to be free for the client-side, or should they also assume some resposibilities as well as the server? Or is it only the server that has to do all the work?
Keep in mind Frihost is a free webhost that chose to allow PHP....they didn't have too. I might add the shockwave/flash plugin is free and under 1mb....just download/install it and you'll be able to see alot more.
Please direct any arguements to me personally via PM.....no need to spam the channel for point/post count.
It is a very rare developer that can pull off a successful flash site.
If flash contnet is necessary in a site, I prefer that it is embedded as an object in a manner that allows the page to function without the flash. (did that come out right?)
Not just because I'm an accessibility advocate, but also just because of my personal preference. I like clean, simple design. Extras should be optional.
I want to choose to take the time to download and view extra content. or not.
And I always try to give the same choice to visitors of sites that I develop!
So the bottom line is - flash only if absolutely necessary. ANd, if necessary, then it must be used skillfully.
If flash contnet is necessary in a site, I prefer that it is embedded as an object in a manner that allows the page to function without the flash. (did that come out right?)
Not just because I'm an accessibility advocate, but also just because of my personal preference. I like clean, simple design. Extras should be optional.
I want to choose to take the time to download and view extra content. or not.
And I always try to give the same choice to visitors of sites that I develop!
So the bottom line is - flash only if absolutely necessary. ANd, if necessary, then it must be used skillfully.
I like regular web sites that embed flash elements
...the best of both worlds.
...the best of both worlds.
I don't mind whether it is a Flash Site or a plain site, as long as it looks good, attractive and worth visiting again and again.
| riv_ wrote: |
| It is a very rare developer that can pull off a successful flash site.
If flash contnet is necessary in a site, I prefer that it is embedded as an object in a manner that allows the page to function without the flash. (did that come out right?) Not just because I'm an accessibility advocate, but also just because of my personal preference. I like clean, simple design. Extras should be optional. I want to choose to take the time to download and view extra content. or not. And I always try to give the same choice to visitors of sites that I develop! So the bottom line is - flash only if absolutely necessary. ANd, if necessary, then it must be used skillfully. |
Very nice to hear from again riv_, I hope you and the family are happy and healthy this easter sunday.
I agree that Flash does have it's drawbacks....now, but as the technology improves it is most certainly to become much more mainstream all over the Internet. My own personal sites are flash based, I [personally] think they are well structured, but not exactly SEO friendly. Which is why I try to talk my clients out basing a business website entirely on flash, not due to load time, with the advent of cable modems and home DSL lines (not a new technology, but one that is fast becoming mainstream non-the-less), the load factor has been minimized. Another factor is nobody can really steal your code from a .swf file.
I do like flash sites because they give a nice impression, but sometimes I just want to do something quick and flash is slower than plain. So my favorite sites are ones that have flash with an option for plain text.
Flash sites break usability conventions for websites unless the developer rebuilds these, which I've never really seen done all the way. Users want to be able to navigate properly using their browser and not pick their way through some proprietary navigation system in a flashy site. For example, you cannot open a link in a new tab unless the developer builds it in. Furthermore, some users don't even have flash installed and/or browsing using a small screen device that can't break down flash components into smaller sections.
So, while in the hands of a professional there can be some great uses for flash, this is probably not you... so avoid flash, please! It's right up there with PDF for bad ways of distributing content, imo. Only use it if you need something animated, and then only embedded.
So, while in the hands of a professional there can be some great uses for flash, this is probably not you... so avoid flash, please! It's right up there with PDF for bad ways of distributing content, imo. Only use it if you need something animated, and then only embedded.
What about a site made totally plain except for a navigation menu in flash?
Anything to do with site navigation should use standard html. It's the content that may or may not be made in flash, depending on the circumstances.
Now, I must mention there are a few cases in which flash sites work. These are usually artistic sites where functionality is secondary to the experience. They are often smaller sites as well.
Now, I must mention there are a few cases in which flash sites work. These are usually artistic sites where functionality is secondary to the experience. They are often smaller sites as well.
Pure flash sites are just horrible. Loading times, bandwidth consumption, usually are hard to navigate. Plain sites get the job done and take little space. Flash is great when used for features inside a plain site that html or other coding just cannot do.
 |