text:
Network Working Group P. Almquist
Request for Comments: 1349 Consultant
Updates: RFCs 1248, 1247, 1195, July 1992
1123, 1122, 1060, 791
Type of Service in the Internet Protocol Suite
Status of This Memo
This document specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "IAB
Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
This memo changes and clarifies some aspects of the semantics of the
Type of Service octet in the Internet Protocol (IP) header. The
handling of IP Type of Service by both hosts and routers is specified
in some detail.
This memo defines a new TOS value for requesting that the network
minimize the monetary cost of transmitting a datagram. A number of
additional new TOS values are reserved for future experimentation and
standardization. The ability to request that transmission be
optimized along multiple axes (previously accomplished by setting
multiple TOS bits simultaneously) is removed. Thus, for example, a
single datagram can no longer request that the network simultaneously
minimize delay and maximize throughput.
In addition, there is a minor conflict between the Host Requirements
(RFC-1122 and RFC-1123) and a number of other standards concerning
the sizes of the fields in the Type of Service octet. This memo
resolves that conflict.
Table of Contents
1. Introduction ............................................... 3
2. Goals and Philosophy ....................................... 3
3. Specification of the Type of Service Octet ................. 4
4. Specification of the TOS Field ............................. 5
Almquist [Page 1]
RFC 1349 Type of Service July 1992 5. Use of the TOS Field in the Internet Protocols ............. 6 5.1 Internet Control Message Protocol (ICMP) ............... 6 5.2 Transport Protocols .................................... 7 5.3 Application Protocols .................................. 7 6. ICMP and the TOS Facility .................................. 8 6.1 Destination Unreachable ................................ 8 6.2 Redirect ............................................... 9 7. Use of the TOS Field in Routing ............................ 9 7.1 Host Routing ........................................... 10 7.2 Forwarding ............................................. 12 8. Other consequences of TOS .................................. 13 APPENDIX A. Updates to Other Specifications ................... 14 A.1 RFC-792 (ICMP) ......................................... 14 A.2 RFC-1060 (Assigned Numbers) ............................ 14 A.3 RFC-1122 and RFC-1123 (Host Requirements) .............. 16 A.4 RFC-1195 (Integrated IS-IS) ............................ 16 A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB) ................ 17 APPENDIX B. Rationale ......................................... 18 B.1 The Minimize Monetary Cost TOS Value ................... 18 B.2 The Specification of the TOS Field ..................... 19 B.3 The Choice of Weak TOS Routing ......................... 21 B.4 The Retention of Longest Match Routing ................. 22 B.5 The Use of Destination Unreachable ..................... 23 APPENDIX C. Limitations of the TOS Mechanism .................. 24 C.1 Inherent Limitations ................................... 24 C.2 Limitations of this Specification ...................... 25 References ..................................................... 27 Acknowledgements ............................................... 28 Security Considerations ........................................ 28 Author's Address ............................................... 28 Almquist [Page 2]
RFC 1349 Type of Service July 1992 1. Introduction Paths through the Internet vary widely in the quality of service they provide. Some paths are more reliable than others. Some impose high call setup or per-packet charges, while others do not do usage-based charging. Throughput and delay also vary widely. Often there are tradeoffs: the path that provides the highest throughput may well not be the one that provides the lowest delay or the lowest monetary cost. Therefore, the "optimal" path for a packet to follow through the Internet may depend on the needs of the application and its user. Because the Internet itself has no direct knowledge of how to optimize the path for a particular application or user, the IP protocol [11] provides a (rather limited) facility for upper layer protocols to convey hints to the Internet Layer about how the tradeoffs should be made for the particular packet. This facility is the "Type of Service" facility, abbreviated as the "TOS facility" in this memo. Although the TOS facility has been a part of the IP specification since the beginning, it has been little used in the past. However, the Internet host specification [1,2] now mandates that hosts use the TOS facility. Additionally, routing protocols (including OSPF [10] and Integrated IS-IS [7]) have been developed which can compute routes separately for each type of service. These new routing protocols make it practical for routers to consider the requested type of service when making routing decisions. This specification defines in detail how hosts and routers use the TOS facility. Section 2 introduces the primary considerations that motivated the design choices in this specification. Sections 3 and 4 describe the Type of Service octet in the IP header and the values which the TOS field of that octet may contain. Section 5 describes how a host (or router) chooses appropriate values to insert into the TOS fields of the IP datagrams it originates. Sections 6 and 7 describe the ICMP Destination Unreachable and Redirect messages and how TOS affects path choice by both hosts and routers. Section 8 describes some additional ways in which TOS may optionally affect packet processing. Appendix A describes how this specification updates a number of existing specifications. Appendices B and C expand on the discussion in Section 2. 2. Goals and Philosophy The fundamental rule that guided this specification is that a host should never be penalized for using the TOS facility. If a host makes appropriate use of the TOS facility, its network service should be at least as good as (and hopefully better than) it would have been Almquist [Page 3]
RFC 1349 Type of Service July 1992 if the host had not used the facility. This goal was considered particularly important because it is unlikely that any specification which did not meet this goal, no matter how good it might be in other respects, would ever become widely deployed and used. A particular consequence of this goal is that if a network cannot provide the TOS requested in a packet, the network does not discard the packet but instead delivers it the same way it would have been delivered had none of the TOS bits been set. Even though the TOS facility has not been widely used in the past, it is a goal of this memo to be as compatible as possible with existing practice. Primarily this means that existing host implementations should not interact badly with hosts and routers which implement the specifications of this memo, since TOS support is almost non-existent in routers which predate this specification. However, this memo does attempt to be compatible with the treatment of IP TOS in OSPF and Integrated IS-IS. Because the Internet community does not have much experience with TOS, it is important that this specification allow easy definition and deployment of new and experimental types of service. This goal has had a significant impact on this specification. In particular, it led to the decision to fix permanently the size of the TOS field and to the decision that hosts and routers should be able to handle a new type of service correctly without having to understand its semantics. Appendix B of this memo provides a more detailed explanation of the rationale behind particular aspects of this specification. 3. Specification of the Type of Service Octet The TOS facility is one of the features of the Type of Service octet in the IP datagram header. The Type of Service octet consists of three fields: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TOS | MBZ | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ The first field, labeled "PRECEDENCE" above, is intended to denote the importance or priority of the datagram. This field is not discussed in detail in this memo. The second field, labeled "TOS" above, denotes how the network should Almquist [Page 4]
RFC 1349 Type of Service July 1992 make tradeoffs between throughput, delay, reliability, and cost. The TOS field is the primary topic of this memo. The last field, labeled "MBZ" (for "must be zero") above, is currently unused. The originator of a datagram sets this field to zero (unless participating in an Internet protocol experiment which makes use of that bit). Routers and recipients of datagrams ignore the value of this field. This field is copied on fragmentation. In the past there has been some confusion about the size of the TOS field. RFC-791 defined it as a three bit field, including bits 3-5 in the figure above. It included bit 6 in the MBZ field. RFC-1122 added bits 6 and 7 to the TOS field, eliminating the MBZ field. This memo redefines the TOS field to be the four bits shown in the figure above. The reasons for choosing to make the TOS field four bits wide can be found in Appendix B.2. 4. Specification of the TOS Field As was stated just above, this memo redefines the TOS field as a four bit field. Also contrary to RFC-791, this memo defines the TOS field as a single enumerated value rather than as a set of bits (where each bit has its own meaning). This memo defines the semantics of the following TOS field values (expressed as binary numbers): 1000 -- minimize delay 0100 -- maximize throughput 0010 -- maximize reliability 0001 -- minimize monetary cost 0000 -- normal service The values used in the TOS field are referred to in this memo as "TOS values", and the value of the TOS field of an IP packet is referred to in this memo as the "requested TOS". The TOS field value 0000 is referred to in this memo as the "default TOS." Because this specification redefines TOS values to be integers rather than sets of bits, computing the logical OR of two TOS values is no longer meaningful. For example, it would be a serious error for a router to choose a low delay path for a packet whose requested TOS was 1110 simply because the router noted that the former "delay bit" was set. Although the semantics of values other than the five listed above are not defined by this memo, they are perfectly legal TOS values, and hosts and routers must not preclude their use in any way. As will become clear after reading the remainder of this memo, only the default TOS is in any way special. A host or router need not (and Almquist [Page 5]
RFC 1349 Type of Service July 1992 except as described in Section 8 should not) make any distinction between TOS values whose semantics are defined by this memo and those that are not. It is important to note the use of the words "minimize" and "maximize" in the definitions of values for the TOS field. For example, setting the TOS field to 1000 (minimize delay) does not guarantee that the path taken by the datagram will have a delay that the user considers "low". The network will attempt to choose the lowest delay path available, based on its (often imperfect) information about path delay. The network will not discard the datagram simply because it believes that the delay of the available paths is "too high" (actually, the network manager can override this behavior through creative use of routing metrics, but this is strongly discouraged: setting the TOS field is intended to give better service when it is available, rather than to deny service when it is not). 5. Use of the TOS Field in the Internet Protocols For the TOS facility to be useful, the TOS fields in IP packets must be filled in with reasonable values. This section discusses how protocols above IP choose appropriate values. 5.1 Internet Control Message Protocol (ICMP) ICMP [8,9,12] defines a number of messages for performing error reporting and diagnostic functions for the Internet Layer. This section describes how a host or router chooses appropriate TOS values for ICMP messages it originates. The TOS facility also affects the origination and processing of ICMP Redirects and ICMP Destination Unreachables, but that is the topic of Section 6. For purposes of this discussion, it is useful to divide ICMP messages into three classes: o ICMP error messages include ICMP message types 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), and 12 (Parameter Problem). o ICMP request messages include ICMP message types 8 (Echo), 10 (Router Solicitation), 13 (Timestamp), 15 (Information Request -- now obsolete), and 17 (Address Mask Request). o ICMP reply messages include ICMP message types 0 (Echo Reply), 9 (Router Advertisement), 14 (Timestamp Reply), 16 (Information Reply -- also obsolete), and 18 (Address Mask Reply). Almquist [Page 6]
RFC 1349 Type of Service July 1992 An ICMP error message is always sent with the default TOS (0000). An ICMP request message may be sent with any value in the TOS field. A mechanism to allow the user to specify the TOS value to be used would be a useful feature in many applications that generate ICMP request messages. An ICMP reply message is sent with the same value in the TOS field as was used in the corresponding ICMP request message. 5.2 Transport Protocols When sending a datagram, a transport protocol uses the TOS requested by the application. There is no requirement that both ends of a transport connection use the same TOS. For example, the sending side of a bulk data transfer application should request that throughput be maximized, whereas the receiving side might request that delay be minimized (assuming that it is primarily sending small acknowledgement packets). It may be useful for a transport protocol to provide applications with a mechanism for learning the value of the TOS field that accompanied the most recently received data. It is quite permissible to switch to a different TOS in the middle of a connection if the nature of the traffic being generated changes. An example of this would be SMTP, which spends part of its time doing bulk data transfer and part of its time exchanging short command messages and responses. TCP [13] should use the same TOS for datagrams containing only TCP control information as it does for datagrams which contain user data. Although it might seem intuitively correct to always request that the network minimize delay for segments containing acknowledgements but no data, doing so could corrupt TCP's round trip time estimates. 5.3 Application Protocols Applications are responsible for choosing appropriate TOS values for any traffic they originate. The Assigned Numbers document [15] lists the TOS values to be used by a number of common network applications. For other applications, it is the responsibility of the application's designer or programmer to make a suitable choice, based on the nature of the traffic to be originated by the application. It is essential for many sorts of network diagnostic applications, and desirable for other applications, that the user of the Almquist [Page 7]
RFC 1349 Type of Service July 1992 application be able to override the TOS value(s) which the application would otherwise choose. The Assigned Numbers document is revised and reissued periodically. Until RFC-1060, the edition current as this is being written, has been superceded, readers should consult Appendix A.2 of this memo. 6. ICMP and the TOS Facility Routers communicate routing information to hosts using the ICMP protocol [12]. This section describes how support for the TOS facility affects the origination and interpretation of ICMP Redirect messages and certain types of ICMP Destination Unreachable messages. This memo does not define any new extensions to the ICMP protocol. 6.1 Destination Unreachable The ICMP Destination Unreachable message contains a code which describes the reason that the destination is unreachable. There are four codes [1,12] which are particularly relevant to the topic of this memo: 0 -- network unreachable 1 -- host unreachable 11 -- network unreachable for type of service 12 -- host unreachable for type of service A router generates a code 11 or code 12 Destination Unreachable when an unreachable destination (network or host) would have been reachable had a different TOS value been specified. A router generates a code 0 or code 1 Destination Unreachable in other cases. A host receiving a Destination Unreachable message containing any of these codes should recognize that it may result from a routing transient. The host should therefore interpret the message as only a hint, not proof, that the specified destination is unreachable. The use of codes 11 and 12 may seem contrary to the statement in Section 2 that packets should not be discarded simply because the requested TOS cannot be provided. The rationale for having these codes and the limited cases in which they are expected to be used are described in Appendix B.5. Almquist [Page 8]
RFC 1349 Type of Service July 1992 6.2 Redirect The ICMP Redirect message also includes a code, which specifies the class of datagrams to which the Redirect applies. There are currently four codes defined: 0 -- redirect datagrams for the network 1 -- redirect datagrams for the host 2 -- redirect datagrams for the type of service and network 3 -- redirect datagrams for the type of service and host A router generates a code 3 Redirect when the Redirect applies only to IP packets which request a particular TOS value. A router generates a code 1 Redirect instead when the the optimal next hop on the path to the destination would be the same for any TOS value. In order to minimize the potential for host confusion, routers should refrain from using codes 0 and 2 in Redirects [3,6]. Although the current Internet Host specification [1] only requires hosts to correctly handle code 0 and code 1 Redirects, a host should also correctly handle code 2 and code 3 Redirects, as described in Section 7.1 of this memo. If a host does not, it is better for the host to treat code 2 as equivalent to code 0 and code 3 as equivalent to code 1 than for the host to simply ignore code 2 and code 3 Redirects. 7. Use of the TOS Field in Routing Both hosts and routers should consider the value of the TOS field of a datagram when choosing an appropriate path to get the datagram to its destination. The mechanisms for doing so are discussed in this section. Whether a packet's TOS value actually affects the path it takes inside of a particular routing domain is a choice made by the routing domain's network manager. In many routing domains the paths are sufficiently homogeneous in nature that there is no reason for routers to choose different paths based up the TOS field in a datagram. Inside such a routing domain, the network manager may choose to limit the size of the routing database and of routing protocol updates by only defining routes for the default (0000) TOS. Neither hosts nor routers should need to have any explicit knowledge of whether TOS affects routing in the local routing domain. Almquist [Page 9]
RFC 1349 Type of Service July 1992 7.1 Host Routing When a host (which is not also a router) wishes to send an IP packet to a destination on another network or subnet, it needs to choose an appropriate router to send the packet to. According to the IP Architecture, it does so by maintaining a route cache and a list of default routers. Each entry in the route cache lists a destination (IP address) and the appropriate router to use to reach that destination. The host learns the information stored in its route cache through the ICMP Redirect mechanism. The host learns the list of default routers either from static configuration information or by using the ICMP Router Discovery mechanism [8]. When the host wishes to send an IP packet, it searches its route cache for a route matching the destination address in the packet. If one is found it is used; if not, the packet is sent to one of the default routers. All of this is described in greater detail in section 3.3.1 of RFC-1122 [1]. Adding support for the TOS facility changes the host routing procedure only slightly. In the following, it is assumed that (in accordance with the current Internet Host specification [1]) the host treats code 0 (redirect datagrams for the network) Redirects as if they were code 1 (redirect datagrams for the host) Redirects. Similarly, it is assumed that the host treats code 2 (redirect datagrams for the network and type of service) Redirects as if they were code 3 (redirect datagrams for the host and type of service) Redirects. Readers considering violating these assumptions should be aware that long and careful consideration of the way in which Redirects are treated is necessary to avoid situations where every packet sent to some destination provokes a Redirect. Because these assumptions match the recommendations of Internet Host specification, that careful consideration is beyond the scope of this memo. As was described in Section 6.2, some ICMP Redirects apply only to IP packets which request a particular TOS. Thus, a host (at least conceptually) needs to store two types of entries in its route cache: type 1: { destination, TOS, router } type 2: { destination, *, router } where type 1 entries result from the receipt of code 3 (or code 1) Redirects and type 2 entries result from the receipt of code 2 (or code 0) Redirects. Almquist [Page 10]
RFC 1349 Type of Service July 1992 When a host wants to send a packet, it first searches the route cache for a type 1 entry whose destination matches the destination address of the packet and whose TOS matches the requested TOS in the packet. If it doesn't find one, the host searches its route cache again, this time looking for a type 2 entry whose destination matches the destination address of the packet. If either of these searches finds a matching entry, the packet is sent to the router listed in the matching entry. Otherwise, the packet is sent to one of the routers on the list of default routers. When a host creates (or updates) a type 2 entry, it must flush from its route cache any type 1 entries which have the same destination. This is necessary for correctness, since the type 1 entry may be obsolete but would continue to be used if it weren't flushed because type 1 entries are always preferred over type 2 entries. However, the converse is not true: when a host creates a type 1 entry, it should not flush a type 2 entry that has the same destination. In this case, the type 1 entry will properly override the type 2 entry for packets whose destination address and requested TOS match the type 1 entry. Because the type 2 entry may well specify the correct router for some TOS values other than the one specified in the type 1 entry, saving the type 2 entry will likely cut down on the number of Redirects which the host would otherwise receive. This savings can potentially be substantial if one of the Redirects which was avoided would have created a new type 2 entry (thereby causing the new type 1 entry to be flushed). That can happen, for example, if only some of the routers on the local net are part of a routing domain that computes separate routes for each TOS. As an alternative, a host may treat all Redirects as if they were code 3 (redirect datagrams for hosts and type of service) Redirects. This alternative allows the host to have only type 1 route cache entries, thereby simplifying route lookup and eliminating the need for the rules in the previous two paragraphs. The disadvantage of this approach is that it increases the size of the route cache and the amount of Redirect traffic if the host sends packets with a variety of requested TOS's to a destination for which the host should use the same router regardless of the requested TOS. There is not yet sufficient experience with the TOS facility to know whether that disadvantage would be serious enough in practice to outweigh the simplicity of this approach. Despite RFC-1122, some hosts acquire their routing information by "wiretapping" a routing protocol instead of by using the Almquist [Page 11]
RFC 1349 Type of Service July 1992 mechanisms described above. Such hosts will need to follow the procedures described in Section 7.2 (except of course that hosts will not send ICMP Destination Unreachables or ICMP Redirects). 7.2 Forwarding A router in the Internet should be able to consider the value of the TOS field when choosing an appropriate path over which to forward an IP packet. How a router does this is a part of the more general issue of how a router picks appropriate paths. This larger issue can be extremely complex [4], and is beyond the scope of this memo. This discussion should therefore be considered only an overview. Implementors should consult the Router Requirements specification [3] and the the specifications of the routing protocols they implement for details. A router associates a TOS value with each route in its forwarding table. The value can be any of the possible values of the TOS field in an IP datagram (including those values whose semantics are yet to be defined). Any routes learned using routing protocols which support TOS are assigned appropriate TOS value by those protocols. Routes learned using other routing protocols are always assigned the default TOS value (0000). Static routes have their TOS values assigned by the network manager. When a router wants to forward a packet, it first looks up the destination address in its forwarding table. This yields a set of candidate routes. The set may be empty (if the destination is unreachable), or it may contain one or more routes to the destination. If the set is not empty, the TOS values of the routes in the set are examined. If the set contains a route whose TOS exactly matches the TOS field of the packet being forwarded then that route is chosen. If not but the set contains a route with the default TOS then that route is chosen. If no route is found, or if the the chosen route has an infinite metric, the destination is considered to be unreachable. The packet is discarded and an ICMP Destination Unreachable is returned to the source. Normally, the Unreachable uses code 0 (Network unreachable) or 1 (Host unreachable). If, however, a route to the destination exists which has a different TOS value and a non-infinite metric then code 11 (Network unreachable for type of service) or code 12 (Host unreachable for type of service) must be used instead. Almquist [Page 12]
RFC 1349 Type of Service July 1992 8. Other consequences of TOS The TOS field in a datagram primarily affects the path chosen through the network, but an implementor may choose to have TOS also affect other aspects of how the datagram is handled. For example, a host or router might choose to give preferential queuing on network output queues to datagrams which have requested that delay be minimized. Similarly, a router forced by overload to discard packets might attempt to avoid discarding packets that have requested that reliability be maximized. At least one paper [14] has explored these ideas in some detail, but little is known about how well such special handling would work in practice. Additionally, some Link Layer protocols have their own quality of service mechanisms. When a router or host transmits an IP packet, it might request from the Link Layer a quality of service as close as possible to the one requested in the TOS field in the IP header. Long ago an attempt (RFC-795) was made to codify how this might be done, but that document describes Link Layer protocols which have since become obsolete and no more recent document on the subject has been written. Almquist [Page 13]
RFC 1349 Type of Service July 1992 APPENDIX A. Updates to Other Specifications While this memo is primarily an update to the IP protocol specification [11], it also peripherally affects a number of other specifications. This appendix describes those peripheral effects. This information is included in an appendix rather than in the main body of the document because most if not all of these other specifications will be updated in the future. As that happens, the information included in this appendix will become obsolete. A.1 RFC-792 (ICMP) RFC-792 [12] defines a set of codes indicating reasons why a destination is unreachable. This memo describes the use of two additional codes: 11 -- network unreachable for type of service 12 -- host unreachable for type of service These codes were defined in RFC-1122 [1] but were not included in RFC-792. A.2 RFC-1060 (Assigned Numbers) RFC-1060 [15] describes the old interpretation of the TOS field (as three independent bits, with no way to specify that monetary cost should be minimized). Although it is likely obvious how the values in RFC-1060 ought to be interpreted in light of this memo, the information from that RFC is reproduced here. The only actual changes are for ICMP (to conform to Section 5.1 of this memo) and NNTP: ----- Type-of-Service Value ----- Protocol TOS Value TELNET (1) 1000 (minimize delay) FTP Control 1000 (minimize delay) Data (2) 0100 (maximize throughput) TFTP 1000 (minimize delay) SMTP (3) Command phase 1000 (minimize delay) DATA phase 0100 (maximize throughput) Almquist [Page 14]
RFC 1349 Type of Service July 1992 ----- Type-of-Service Value ----- Protocol TOS Value Domain Name Service UDP Query 1000 (minimize delay) TCP Query 0000 Zone Transfer 0100 (maximize throughput) NNTP 0001 (minimize monetary cost) ICMP Errors 0000 Requests 0000 (4) Responses <same as request> (4) Any IGP 0010 (maximize reliability) EGP 0000 SNMP 0010 (maximize reliability) BOOTP 0000 Notes: (1) Includes all interactive user protocols (e.g., rlogin). (2) Includes all bulk data transfer protocols (e.g., rcp). (3) If the implementation does not support changing the TOS during the lifetime of the connection, then the recommended TOS on opening the connection is the default TOS (0000). (4) Although ICMP request messages are normally sent with the default TOS, there are sometimes good reasons why they would be sent with some other TOS value. An ICMP response always uses the same TOS value as was used in the corresponding ICMP request message. See Section 5.1 of this memo. An application may (at the request of the user) substitute 0001 (minimize monetary cost) for any of the above values. This appendix is expected to be obsoleted by the next revision of the Assigned Numbers document. Almquist [Page 15]
RFC 1349 Type of Service July 1992 A.3 RFC-1122 and RFC-1123 (Host Requirements) The use of the TOS field by hosts is described in detail in RFC-1122 [1] and RFC-1123 [2]. The information provided there is still correct, except that: (1) The TOS field is four bits wide rather than five bits wide. The requirements that refer to the TOS field should refer only to the four bits that make up the TOS field. (2) An application may set bit 6 of the TOS octet to a non-zero value (but still must not set bit 7 to a non-zero value). These details will presumably be corrected in the next revision of the Host Requirements specification, at which time this appendix can be considered obsolete. A.4 RFC-1195 (Integrated IS-IS) Integrated IS-IS (sometimes known as Dual IS-IS) has multiple metrics for each route. Which of the metrics is used to route a particular IP packet is determined by the TOS field in the packet. This is described in detail in section 3.5 of RFC-1195 [7]. The mapping from the value of the TOS field to an appropriate Integrated IS-IS metric is described by a table in that section. Although the specification in this memo is intended to be substantially compatible with Integrated IS-IS, the extension of the TOS field to four bits and the addition of a TOS value requesting "minimize monetary cost" require minor modifications to that table, as shown here: The IP TOS octet is mapped onto the four available metrics as follows: Bits 0-2 (Precedence): (unchanged from RFC-1195) Bits 3-6 (TOS): 0000 (all normal) Use default metric 1000 (minimize delay) Use delay metric 0100 (maximize throughput) Use default metric 0010 (maximize reliability) Use reliability metric 0001 (minimize monetary cost) Use cost metric other Use default metric Bit 7 (MBZ): This bit is ignored by Integrated IS-IS. Almquist [Page 16]
RFC 1349 Type of Service July 1992 It is expected that the next revision of the Integrated IS-IS specification will include this corrected table, at which time this appendix can be considered obsolete. A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB) Although the specification in this memo is intended to be substantially compatible with OSPF, the extension of the TOS field to four bits requires minor modifications to the section that describes the encoding of TOS values in Link State Advertisements, described in section 12.3 of RFC-1247 [10]. The encoding is summarized in Table 17 of that memo; what follows is an updated version of table 17. The numbers in the first column are decimal integers, and the numbers in the second column are binary TOS values: OSPF encoding TOS _____________________________________________ 0 0000 normal service 2 0001 minimize monetary cost 4 0010 maximize reliability 6 0011 8 0100 maximize throughput 10 0101 12 0110 14 0111 16 1000 minimize delay 18 1001 20 1010 22 1011 24 1100 26 1101 28 1110 30 1111 The OSPF MIB, described in RFC-1248 [5], is entirely consistent with this memo except for the textual comment which describes the mapping of the old TOS flag bits into TOSType values. TOSType values use the same encoding of TOS values as OSPF's Link State Advertisements do, so the above table also describes the mapping between TOSType values (the first column) and TOS field values (the second column). If RFC-1247 and RFC-1248 are revised in the future, it is expected that this information will be incorporated into the revised versions. At that time, this appendix may be considered obsolete. Almquist [Page 17]
RFC 1349 Type of Service July 1992 APPENDIX B. Rationale The main body of this memo has described the details of how TOS facility works. This appendix is for those who wonder why it works that way. Much of what is in this document can be explained by the simple fact that the goal of this document is to provide a clear and complete specification of the existing TOS facility rather than to design from scratch a new quality of service mechanism for IP. While this memo does amend the facility in some small and carefully considered ways discussed below, the desirability of compatibility with existing specifications and uses of the TOS facility [1,2,7,10,11] was never in doubt. This goal of backwards compatibility determined the broad outlines and many of the details of this specification. Much of the rest of this specification was determined by two additional goals, which were described more fully in Section 2. The first was that hosts should never be penalized for using the TOS facility, since that would likely ensure that it would never be widely deployed. The second was that the specification should make it easy, or at least possible, to define and deploy new types of service in the future. The three goals above did not eliminate all need for engineering choices, however, and in a few cases the goals proved to be in conflict with each other. The remainder of this appendix discusses the rationale behind some of these engineering choices. B.1 The Minimize Monetary Cost TOS Value Because the Internet is becoming increasingly commercialized, a number of participants in the IETF's Router Requirements Working Group felt it would be important to have a TOS value which would allow a user to declare that monetary cost was more important than other qualities of the service. There was considerable debate over what exactly this value should mean. Some felt, for example, that the TOS value should mean "must not cost money". This was rejected for several reasons. Because it would request a particular level of service (cost = 0) rather than merely requesting that some service attribute be minimized or maximized, it would not only philosophically at odds with the other TOS values but would require special code in both hosts and routers. Also, it would not be helpful to users who want their packets to travel via the least-cost path but can accept some level of cost when necessary. Finally, since whether any particular routing domain considers the TOS field when routing Almquist [Page 18]
RFC 1349 Type of Service July 1992 is a choice made by the network manager, a user requiring a free path might not get one if the packet has to pass through a routing domain that does not consider TOS in its routing decisions. Some proposed a slight variant: a TOS value which would mean "I am willing to pay money to have this packet delivered". This proposal suffers most of the same shortcomings as the previous one and turns out to have an additional interesting quirk: because of the algorithms specified in Section 7.2, any packet which used this TOS value would prefer links that cost money over equally good free links. Thus, such a TOS value would almost be equivalent to a "maximize monetary cost" value! It seems likely that in the future users may need some mechanism to express the maximum amount they are willing to pay to have a packet delivered. However, an IP option would be a more appropriate mechanism, since there are precedents for having IP options that all routers are required to honor, and an IP option could include parameters such as the maximum amount the user was willing to pay. Thus, the TOS value defined in this memo merely requests that the network "minimize monetary cost". B.2 The Specification of the TOS Field There were four goals that guided the decision to have a four bit TOS field and the specification of that field's values: (1) To define a new type of service requesting that the network "minimize monetary cost" (2) To remain as compatible as possible with existing specifications and uses of the TOS facility (3) To allow for the definition and deployment of new types of service in the future (4) To permanently fix the size of the TOS field The last goal may seem surprising, but turns out to be necessary for routing to work correctly when new types of service are deployed. If routers have different ideas about the size of the TOS field they make inconsistent decisions that may lead to routing loops. At first glance goals (3) and (4) seem to be pretty much mutually exclusive. The IP header currently has only three unused bits, so at most three new type of service bits could be defined without resorting to the impractical step of changing the IP header Almquist [Page 19]
RFC 1349 Type of Service July 1992 format. Since one of them would need to be allocated to meet goal (1), at most two bits could be reserved for new or experimental types of service. Not only is it questionable whether two would be enough, but it is improbable that the IETF and IAB would allow all of the currently unused bits to be permanently reserved for types of service which might or might or might not ever be defined. However, some (if not most of) the possible combinations of the individual bits would not be useful. Clearly, setting all of the bits would be equivalent to setting none of the bits, since setting all of the bits would indicate that none of the types of optimization was any more important than any of the others. Although one could perhaps assign reasonable semantics to most pairs of bits, it is unclear that the range of network service provided by various paths could usefully be subdivided in so fine a manner. If some of these non-useful combinations of bits could be assigned to new types of service then it would be possible to meet goal (3) and goal (4) without having to use up all of the remaining reserved bits in the IP header. The obvious way to do that was to change the interpretation of TOS values so that they were integers rather than independently settable bits. The integers were chosen to be compatible with the bit definitions found in RFC-791. Thus, for example, setting the TOS field to 1000 (minimize delay) sets bit 3 of the Type of Service octet; bit 3 is defined as the Low Delay bit in RFC-791. This memo only defines values which correspond to setting a single one of the RFC-791 bits, since setting multiple TOS bits does not seem to be a common practice. According to [15], none of the common TCP/IP applications currently set multiple TOS bits. However, TOS values corresponding to particular combinations of the RFC-791 bits could be defined if and when they are determined to be useful. The new TOS value for "minimize monetary cost" needed to be one which would not be too terribly misconstrued by preexisting implementations. This seemed to imply that the value should be one which left all of the RFC-791 bits clear. That would require expanding the TOS field, but would allow old implementations to treat packets which request minimization of monetary cost (TOS 0001) as if they had requested the default TOS. This is not a perfect solution since (as described above) changing the size of the TOS field could cause routing loops if some routers were to route based on a three bit TOS field and others were to route based on a four bit TOS field. Fortunately, this should not be much of a problem in practice because routers which route based on a three bit TOS field are very rare as this is being written and will only become more so once this specification is published. Almquist [Page 20]
RFC 1349 Type of Service July 1992 Because of those considerations, and also in order to allow a reasonable number of TOS values for future definition, it seemed desirable to expand the TOS field. That left the question of how much to expand it. Expanding it to five bits would allow considerable future expansion (27 new TOS values) and would be consistent with Host Requirements, but would reduce to one the number of reserved bits in the IP header. Expanding the TOS field to four bits would restrict future expansion to more modest levels (11 new TOS values), but would leave an additional IP header bit free. The IETF's Router Requirements Working Group concluded that a four bits wide TOS field allow enough values for future use and that consistency with Host Requirements was inadequate justification for unnecessarily increasing the size of the TOS field. B.3 The Choice of Weak TOS Routing "Ruminations on the Next Hop" [4] describes three alternative ways of routing based on the TOS field. Briefly, they are: (1) Strong TOS -- a route may be used only if its TOS exactly matches the TOS in the datagram being routed. If there is no route with the requested TOS, the packet is discarded. (2) Weak TOS -- like Strong TOS, except that a route with the default TOS (0000) is used if there is no route that has the requested TOS. If there is no route with either the requested TOS or the default TOS, the packet is discarded. (3) Very Weak TOS -- like Weak TOS, except that a route with the numerically smallest TOS is used if there is no route that has either the requested TOS or the default TOS. This specification has adopted Weak TOS. Strong TOS was quickly rejected. Because it requires that each router a packet traverses have a route with the requested TOS, packets which requested non-zero TOS values would have (at least until the TOS facility becomes widely used) a high probability of being discarded as undeliverable. This violates the principle (described in Section 2) that hosts should not be penalized for choosing non-zero TOS values. The choice between Weak TOS and Very Weak TOS was not as straightforward. Weak TOS was chosen because it is slightly Almquist [Page 21]
RFC 1349 Type of Service July 1992 simpler to implement and because it is consistent with the OSPF and Integrated IS-IS specifications. In addition, many dislike Very Weak TOS because its algorithm for choosing a route when none of the available routes have either the requested or the default TOS cannot be justified by intuition (there is no reason to believe that having a numerically smaller TOS makes a route better). Since a router would need to understand the semantics of all of the TOS values to make a more intelligent choice, there seems to be no reasonable way to fix this particular deficiency of Very Weak TOS. In practice it is expected that the choice between Weak TOS and Very Weak TOS will make little practical difference, since (except where the network manager has intentionally set things up otherwise) there will be a route with the default TOS to any destination for which there is a route with any other TOS. B.4 The Retention of Longest Match Routing An interesting issue is how early in the route choice process TOS should be considered. There seem to be two obvious possibilities: (1) Find the set of routes that best match the destination address of the packet. From among those, choose the route which best matches the requested TOS. (2) Find the set of routes that best match the requested TOS. From among those, choose the route which best matches the destination address of the packet. The two approaches are believed to support an identical set of routing policies. Which of the two allows the simpler configuration and minimizes the amount of routing information that needs to be passed around seems to depend on the topology, though some believe that the second option has a slight edge in this regard. Under the first option, if the network manager neglects some pieces of the configuration the likely consequence is that some packets which would benefit from TOS-specific routes will be routed as if they had requested the default TOS. Under the second option, however, a network manager can easily (accidently) configure things in such a way that packets which request a certain TOS and should be delivered locally will instead follow a default route for that TOS and be dumped into the Internet. Thus, the first option would seem to have a slight edge with regard to robustness in the face of errors by the network manager. Almquist [Page 22]
RFC 1349 Type of Service July 1992 It has been also been suggested that the first option provides the additional benefit of allowing loop-free routing in routing domains which contain both routers that consider TOS in their routing decisions and routers that do not. Whether that is true in all cases is unknown. It is certainly the case, however, that under the second option it would not work to mix routers that consider TOS and routers which do not in the same routing domain. All in all, there were no truly compelling arguments for choosing one way or the other, but it was nontheless necessary to make a choice: if different routers were to make the choice differently, chaos (in the form of routing loops) would result. The mechanisms specified in this memo reflect the first option because that will probably be more intuitive to most network managers. Internet routing has traditionally chosen the route which best matches the destination address, with other mechanisms serving merely as tie- breakers. The first option is consistent with that tradition. B.5 The Use of Destination Unreachable Perhaps the most contentious and least defensible part of this specification is that a packet can be discarded because the destination is considered to be unreachable even though a packet to the same destination but requesting a different TOS would have been deliverable. This would seem to fall perilously close to violating the principle that hosts should never be penalized for requesting non-default TOS values in packets they originate. This can happen in only three, somewhat unusual, cases: (1) There is a route to the packet's destination which has the TOS value requested in the packet, but the route has an infinite metric. (2) The only routes to the packet's destination have TOS values other than the one requested in the packet. One of them has the default TOS, but it has an infinite metric. (3) The only routes to the packet's destination have TOS values other than the one requested in the packet. None of them have the default TOS. It is commonly accepted that a router which has a default route should nonetheless discard a packet if the router has a more specific route to the destination in its forwarding table but that route has an infinite metric. The first two cases seem to be analogous to that rule. Almquist [Page 23]
RFC 1349 Type of Service July 1992 In addition, it is worth noting that, except perhaps during brief transients resulting from topology changes, routes with infinite metrics occur only as the result of deliberate action (or serious error) on the part of the network manager. Thus, packets are unlikely to be discarded unless the network manager has taken deliberate action to cause them to be. Some people believe that this is an important feature of the specification, allowing the network to (for example) keep packets which have requested that cost be minimized off of a link that is so expensive that the network manager feels confident that the users would want their packets to be dropped. Others (including the author of this memo) believe that this "feature" will prove not to be useful, and that other mechanisms may be required for access controls on links, but couldn't justify changing this specification in the ways necessary to eliminate the "feature". Case (3) above is more problematic. It could have been avoided by using Very Weak TOS, but that idea was rejected for the reasons discussed in Appendix B.3. Some suggested that case (3) could be fixed by relaxing longest match routing (described in Appendix B.4), but that idea was rejected because it would add complexity to routers without necessarily making their routing choices particularly more intuitive. It is also worth noting that this is another case that a network manager has to try rather hard to create: since OSPF and Integrated IS-IS both enforce the constraint that there must be a route with the default TOS to any destination for which there is a route with a non-zero TOS, a network manager would have to await the development of a new routing protocol or create the problem with static routes. The eventual conclusion was that any fix to case (3) was worse than the problem. APPENDIX C. Limitations of the TOS Mechanism It is important to note that the TOS facility has some limitations. Some are consequences of engineering choices made in this specification. Others, referred to as "inherent limitations" below, could probably not have been avoided without either replacing the TOS facility defined in RFC-791 or accepting that things wouldn't work right until all routers in the Internet supported the TOS facility. C.1 Inherent Limitations The most important of the inherent limitations is that the TOS facility is strictly an advisory mechanism. It is not an appropriate mechanism for requesting service guarantees. There are two reasons why this is so: Almquist [Page 24]
RFC 1349 Type of Service July 1992 (1) Not all networks will consider the value of the TOS field when deciding how to handle and route packets. Partly this is a transition issue: there will be a (probably lengthy) period when some networks will use equipment that predates this specification. Even long term, however, many networks will not be able to provide better service by considering the value of the TOS field. For example, the best path through a network composed of a homogeneous collection of interconnected LANs is probably the same for any possible TOS value. Inside such a network, it would make little sense to require routers and routing protocols to do the extra work needed to consider the value of the TOS field when forwarding packets. (2) The TOS mechanism is not powerful enough to allow an application to quantify the level of service it desires. For example, an application may use the TOS field to request that the network choose a path which maximizes throughput, but cannot use that mechanism to say that it needs or wants a particular number of kilobytes or megabytes per second. Because the network cannot know what the application requires, it would be inappropriate for the network to decide to discard a packet which requested maximal throughput because no "high throughput" path was available. The inability to provide resource guarantees is a serious drawback for certain kinds of network applications. For example, a system using packetized voice simply creates network congestion when the available bandwidth is inadequate to deliver intelligible speech. Likewise, the network oughtn't even bother to deliver a voice packet that has suffered more delay in the network than the application can tolerate. Unfortunately, resource guarantees are problematic in connectionless networks. Internet researchers are actively studying this problem, and are optimistic that they will be able to invent ways in which the Internet Architecture can evolve to support resource guarantees while preserving the advantages of connectionless networking. C.2 Limitations of this Specification There are a couple of additional limitations of the TOS facility which are not inherent limitations but instead are consequences of engineering choices made in this specification: (1) Routing is not really optimal for some TOS values. This is because optimal routing for those TOS values would require that routing protocols be cognizant of the semantics of the TOS values and use special algorithms to compute routes for Almquist [Page 25]
RFC 1349 Type of Service July 1992 them. For example, routing protocols traditionally compute the metric for a path by summing the costs of the individual links that make up the path. However, to maximize reliability, a routing protocol would instead have to compute a metric which was the product of the probabilities of successful delivery over each of the individual links in the path. While this limitation is in some sense a limitation of current routing protocols rather than of this specification, this specification contributes to the problem by specifying that there are a number of legal TOS values that have no currently defined semantics. (2) This specification assumes that network managers will do "the right thing". If a routing domain uses TOS, the network manager must configure the routers in such a way that a reasonable path is chosen for each TOS. While this ought not to be terribly difficult, a network manager could accidently or intentionally violate our rule that using the TOS facility should provide service at least as good as not using it. Almquist [Page 26]
RFC 1349 Type of Service July 1992 References [1] Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989. [2] Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989. [3] Almquist, P., "Requirements for IP Routers", Work in progress. [4] Almquist, P., "Ruminations on the Next Hop", Work in progress. [5] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1248, ACC, Computer Science Center, August 1991. [6] Braden, R. and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987. [7] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, Digital Equipment Corporation, December 1990. [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [9] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", RFC 950, USC/Information Sciences Institute, August 1985. [10] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991. [11] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981. [12] Postel, J., "Internet Control Message Protocol", RFC 792, DARPA, September 1981. [13] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, September 1981. [14] Prue, W. and J. Postel, "A Queuing Algorithm to Provide Type- of-Service for IP Links", RFC 1046, USC/Information Sciences Institute, February 1988. [15] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. Almquist [Page 27]
RFC 1349 Type of Service July 1992
Some of the ideas presented in this memo are based on discussions
held by the IETF's Router Requirements Working Group. Much of the
specification of the treatment of Type of Service by hosts is merely
a restatement of the ideas of the IETF's former Host Requirements
Working Group, as captured in RFC-1122 and RFC-1123. The author is
indebted to John Moy and Ross Callon for their assistance and
cooperation in achieving consistency among the OSPF specification,
the Integrated IS-IS specification, and this memo.
This memo has been substantially improved as the result of thoughtful
comments from a number of reviewers, including Dave Borman, Bob
Braden, Ross Callon, Vint Cerf, Noel Chiappa, Deborah Estrin, Phill
Gross, Bob Hinden, Steve Huston, Jon Postel, Greg Vaudreuil, John
Wobus, and the Router Requirements Working Group.
The initial work on this memo was done while its author was an
employee of BARRNet. Their support is gratefully acknowledged.
Security Considerations
This memo does not explicitly discuss security issues. The author
does not believe that the specifications in this memo either weaken
or enhance the security of the IP Protocol or of the other protocols
mentioned herein.
Author's Address
Philip Almquist
214 Cole Street, Suite 2
San Francisco, CA 94117-1916
Phone: 415-752-2427
Email: email@example.com
Almquist [Page 28]


text:
Get the Look
1. Shampoo hair with Total Results Sleek Shampoo, rinse and towel dry. Section hair into four quadrants. Starting at the nape, take ½-inch horizontal partings and apply 2-3 pumps of Opti.smooth Pre-Treat from scalp to ends. Complete entire head.
2. Outline the back left and right with Opti.smooth Smoothing Cream. Using ¼- to ½-inch horizontal sub-sections, apply smoothing crème starting 1/8 -inch off the scalp to the first 1½ inches of hair with a comb. Work half way up the head, then repeat on left side. Continue working right-to-left and complete the back. Apply smoothing crème to ends using a wide-tooth comb and gently scrunch again. Work side-to-side, scrunching remaining hair.
What you'll need
- Wide tooth comb
- Total Results Sleek Shampoo
- Opti.smooth Pre-Treat
- Opti.smooth Smoothing Cream
3. Process for 15-30 minutes, depending on hair type and desired curl pattern.
4. After processing, rinse with warm water and use a scrunching technique for 7-10 minutes. Towel blot and gently detangle using a wide-tooth comb.
MORE: How to Wrap and Roll Your Curls

subset: commoncrawl


text:
Sensual sexy Dakota Skye has asked her man to join her in her dorm room, and now this blonde coed is bent on seduction! She struts out in a crop-top and miniskirt that offer alluring glimpses of her tits and ass, and knee-high socks that complete the naughty schoolgirl outfit.Settling down on her bunk bed she gives her man a show, masturbating in front of him as she entices him into her arms for a hot fuck. She gets her guy all warmed up with a big blowjob, licking and sucking his dick until he's rock hard and ready to slide deep into her tight wet pussy.Taking advantage of Dakota's bunk bed layout, the couple enjoys some standing sex with the help of the ladder and then some acrobatic cowgirl with the help of the slats from the top bunk. All the while Dakota moans her approval of the proper pussy pounding her man delivers until she comes apart in his arms as her climax explodes through her!Moments later her guy releases his load deep in Dakota's twat, glutting her with his cum as she enjoys the full sweet feeling of a proper creampie.
Come To My Room – S3:E4
0 views
Related videos
11 06:10
3 06:13
13 06:13
3 06:22
16 06:23
15 06:16
10 06:31
9 06:09


text:
Did France gain anything significant (territories or other concessions) at the conclusion of the American Revolutionary War? I tried to look up for it, but what I found were very minor (Senegal in Africa and the island of Tobago). This looked very minor for one of the major victors in the war and compared to huge French losses during the Seven Years War.
Did France receive other kind of compensation? If not, why did they receive so little gain as victor?


text:
You can look through the services listed below and call the agencies directly.
You can look through the services listed below and call the agencies directly.
You can contact us via e-mail or by phone at 1-877-271-7611, and a representative will help you find the services that will best serve you and your family.
You can answer a short questionaire by clicking here and a parentPRO representative will find the services that will best serve you and your family.
Get connected with a family support program staffed by a specially trained professional who teach parenting skills and child developments, as well as ways to reduce stress and nurture your child. We can connect you to other resources in your community in order to meet your family's needs.
Address: 620 S. Flynn Street Alva, OK 73171
Contact: Kathy Gordon
Telephone: (580) 327-2900
Website: www.northwestfamily.net
Enrollment Criteria: Pregnant women, moms, dads, and guardians of young children birth to kindergarten
Services include evaluation services, case management, family training, counseling, and home visits, certain health services, nursing & nutrition services, occupational, physical, and speech-language therapy, and special instruction. Can be provided in home or at daycare.
Address: Garfield County Health Department - SoonerStart P.O. Box 3266 Enid, OK 73702
Contact: Please ask for SoonerStart
Telephone: (580) 233-0650
Website: SoonerStart
State Lead: Mark Sharp, Executive Director, Special Education Services
Qualification Criteria: Developmentally delayed infants and toddlers birth – 36 months.


text:
Baby Pink Color Pure Banarasi Handloom Katan Silk Saree- All Over Sona Rupa Jaal Work
Material |
Measurements |
Colour: |
Wash Care: |
Design Detail: Banarasi woven design saree, has a handloom design border . All Banarasi Sarees are our stylist's collection, see the image for a mock-up of what the actual Saree would look like.
Origin: Banarasi sarees originate from the city of Uttar Pradesh in India Named Varanasi or Banaras or Kashi. These are well known for the Mughal Era inspired because of designs are in golden as well as silver brocade or Zari works.
Product Note: This is a handcrafted product from weavers and therefore, slight variation in colors or design may occur. Any slight irregularities are inherent and distinctive to the beauty of this creation due to the nature of the products.
Complete The Look: Look dashing in this feminine traditional saree is a Handloom Saree. Design with woven and the perfect suits when you're going out to celebrate a loved one's engagement, wedding etc.
Expected Delivery: Within 7-10 business days from the date of your order. Shipping: Free shipping all over India and over 30000 shopping you will get free shipping internationally. GST: Price is inclusive of 5% GST |


text:
In this text written by Working Group "Just Do It!" of AntiFa AK Cologne, the authors lay out the perspective of "antinational communism". Published March 2012.
The following article was written in the context of the mobilisation for the international project "M31", a European day of action against capitalism and the crisis. It is a first attempt to describe our approach of "antinational communism"*. Antinationalism is a fairly new, German-specific perspective on left-wing radical politics. It came about in the early 90s in Germany as a reaction to the reunification of a new, greater Germany and the occurrences of racism/fascism by a reactionary civil society. What is its central tenet? Nationalism or – to be more precise – the idea of the nation itself is seen as the central ideology, the all-time dominant, undeniable category in the global, oppressing power relation of capitalism and the capitalist state, which we want to see abolished. From our point of view, an antinational perspective goes beyond traditional left-wing approaches (classical anti-imperialism). And yet, we do not like to focus on Germany and its specifics alone and instead pick up a certain idea of international networking. We want to free this approach from its Germany-focussed isolation and – especially now at a time of crisis, when we can develop transnational reference points – start discussions with comrades in other European countries. Hence we decided to call this approach "international antinationalism". This is also one of the main motivations for us and our antinational, German-wide network "…ums Ganze!" to engage in the project "M31", which was largely initiated out of Germany.
*For us, communism has so far never existed. Communism is "the real movement which abolishes the present state of things" (Marx), i.e. the total negation of the present, capitalist world order for an emancipated, liberated society. The Soviet Union and "real-existing socialism" never was able to get rid of certain basic-capitalist categories, like value or wage labour. Thus, our use of the term communism distances itself from historic attempts at "Real Socialism".
See more:
International Antinationalism!
Five years after the start of the financial crisis, after the insurrections in the Arab region, after intense protests against worsening living and working conditions – after all these developments, finally the German Left is having discussions about the crisis. It seems to become obvious that partial struggles within and against the spheres of production and reproduction are not able to resist against the austerity measures of the Troika (European Union, European Central Bank, International Monetary Fund). This experience has led to different movements and different struggles emerging in these last years, which are looking for common reference points. These transnational movements – whether we think of "Occupy" or the "Arab spring" – are proof that actions which relate to each other are capable of creating new dynamics and of disrupting – at least on the level of ideas traditional conceptions of political terrain (thinking and acting within one's "own" national territory; the nation as a firm category).
Still, all these new movements share the same problem: when it comes to the point of articulating critique and demands, we find only vague abstractions rather than specifics. At the same time, they do retain a certain intuitiveness about the capacity of collective action. This idea of revolt is opposed – from within the "European Left" – by the supporters of a state idealism in two related, yet polarised, ways: the first way claims that social movements can manage to become relevant forces in politics only by relying on a "moral basis". This perspective agitates for the "Idea of Europe" as a common denominator for the different movements and encourages it against the current EUROpe of austerity measures. The second way advocates a politics, which has allegedly been robbed of its true power by "the evil incarnate" (the banksters). This perspective views the aim of struggle as the establishment of a sovereign authority, which would set the framework for the possibility of social reforms. In what follows, we are going to criticise both ways in order to show their reactionary role in the current discussions, and to illustrate our programme for a social offensive. Furthermore, we are going to suggest a different approach for social revolt, derived from our critique of state and capital. We shall call this approach "international antinationalism".
The "Idea of Europe" vs. EUROpe
Whether in school, in university or in leftist feature pages – the "Idea of Europe" is a sacred cow. Especially in times of crisis and wars, it is beyond any criticism. In the midst of World War I, the German philosopher Georg Simmel understood exactly what the "Idea of Europe" is about and what it opposes: "The belief and spirit of internationalism [...] is an altogether secondary phenomenon [...] and an enemy of one's own rooted national character. Europeanism, on the other hand, is an idea, an altogether primary phenomenon not attainable by accumulation or abstraction – however late its appearance as a historical force. It does not exist in between individual nations, it exists beyond them, and is thus perfectly compatible with an individual national life."
Beyond the speculative search for difference and commonality of national identities – so typical for nationalists – Simmel recognizes within the "Idea of Europe" the benefit to one's own nation of guarding the latter against the "virus" of the worker's movement's all-pervasive internationalism. Still today, the "Idea of Europe" serves this function. Furthermore, the value of the "Idea of Europe", in its "idealism", lies in its perspective on ideological crisis management. The Prussian state-political philosopher Hegel wrote: "It is often said, for the sake of edification, that war makes short work of the vanity of temporal things. It is the element by which the idealization of what is particular receives its right and becomes an actuality." "Idealisation", the value of Europe, is not just some philosophical chit-chat outside of world affairs; it is a matter of great priority for European states that their citizens accept the "Idea of Europe" as an "ideal" and that they renounce the "vanity of temporal things".
But what exactly is the "Idea of Europe" anyway? A lot of pens have been put to paper to answer this question and a great deal of nonsense has been the result. The most honest answer, however, was given by the outgoing president of the European Central Bank – Jean Claude Trichet – with the following description: "Our model was the united American Market. If we wanted peace and prosperity, it was said at the time, we needed to benefit from the same economies of scale, from the same free markets as did the United States. This was the vision of the founding fathers of Europe. If that was true back then, it is even more so today". Nowadays it is widely known that it was primarily Germany who benefited from these free markets and whose export surplus ruined other national economies in Europe, such as that of Greece. In order to keep the "Idea of Europe" going, they now "speak German" in Europe, by which we mean the impoverishment of the masses to enable the realisation of capital valorisation.
L'Etat pour moi
In times of crisis, it is not only bankrupt car manufacturers or banks in need of a bailout that are calling for the strong state. The Left, too, sees itself vindicated once more. Financial capital, helped by ruthless parliamentarians, has sold "politics" down the river, it claims. Enchanted by the benevolence of "financial markets", nation-states were no longer able to carry out their true function of pleasing their people's needs, it alleges.
Alongside such rather simplistic approaches, there are also many academic versions of the same. What they have in common is a glorified image of the "golden age of capitalism" (Eric Hobsbawm). According to such claims, the intervention of the state – including its ideological support in mid-20th century, Keynesianism – was not a result of tendencies of monopolisation (imperialism), problems in the production of surplus value (Paul Mattik) and the struggles of rebellious workers (Beverly Silver); rather it is supposed to represent a dubious "class compromise", which pointed at an advantageous "power balance" for the working classes. This reading does not only deny the inner historicity of capital, but it focuses the struggle for a liberated society on the state, the territory of its defeat. Accordingly, the "capitalist state" (Friedrich Engels uses the term "ideeller Gesamtkapitalist" which translates roughly as the "ideal personification of the total national capital") had the obscure, a-historical potential to ban forever, by sovereign dictum, all tendencies for crisis and to guarantee the permanent valorisation of value.
And hence, the global accumulation of capital needs nothing more than to create a "true demand" in the market as well as new "leading technologies" by means of a "green capitalism", all for the achievement of new profits. Alone the fact that the elites and bosses do not show any interest in any such pragmatic proposals to extend exploitation and oppression hints at the fading sovereignty of state authority. It is this "left-wing faith" in the power of the state that gave impetus to the Greek Stalinists (KKE) sending its gangs of "thugs" to protect the parliament in Athens from other protesters during the election of a new austerity package. He who seeks the power of the state has to prevent its dissolution by dissolving the revolt.
What to do? - Determining our position
In recent years, some antinational projects have tried to make international connections. Although a lack of capacity meant that larger initiatives were not possible, such efforts did maintain a common theoretical frame: a clear dissociation from those on the Left that support the state, as well as the rejection of the idea of "national solidarity" ("Solidarität der Völker"). In order to strengthen the idea of a "revolutionary defeatism" (a concept Lenin opposed to "social patriotism" – the ed.) we took action – locally and further afield – against global companies with headquarters in Germany or against German and European institutions. Our activities sought to criticise the nation-state as the unquestioned centre of all politics and to symbolically deny that a whole country could benefit from the business carried out by individual companies. Beyond that, we tried to open communication channels with those people that had already taken to revolt, with limited success.
In this context, we supported two Germany-wide days of actions called for by the campaign "Antifa Tehran". These actions expressed solidarity with the insurrection against the Islamist regime of Iran in 2009 and publicly outed German companies involved in dirty business with the Iranian government. Critical research showed that German businesses supported the IRI regime, which was sanctioned by the state. Crucially for this campaign, the most direct and widespread signal of solidarity that we could send to the Iranian protesters at the time was a blockade of the Iranian consulate in Frankfurt. Unfortunately, it was hard to receive wider, left-wing support for this, because the traditional Left's reception of the political case of Iran and its limited competence to adequately respond to the events of 2009 proved to be an insurmountable stumbling block.
We made very different experiences as part of our participation in the global "day of action against Eurest" (Eurest is a catering and canteen multinational – the ed.), organised by our comrades from the Industrial Workers of the World; the employees of the Ford-canteen in Cologne experienced direct solidarity by other Eurest-workers worldwide, be they in New York or Frankfurt, who supported the Ford-workers in their struggle against Eurest and the Ford management. Maybe this was a small sign that in times of national competition for jobs, a competition perpetuated even by trade unions, parts of the working class are still aware of the importance of solidarity. Our aim, however, remains to broach the issue of international networking of wage-labourers reflecting transnational chains of capital valorisation in order to revive the question of "workplace bargaining power" (Silver) in the "hidden abode of production" (Marx).
In 2011, an unpredictable wave of practical solidarity reached a new peak in Germany: the eviction of the squat "Liebig 14" led to a permanent status of alert for several police units in the whole of Germany. Indeed, Berlin and other cities in Germany saw massive, spontaneous clashes. This must be understood as a reaction to the state fantasising about more evictions, for example that of the notorious squat "Rote Flora" in Hamburg.
These chain reactions of solidarity reminded us of the international response to the 2008 December riots in Greece. The occupation of the Greek embassy in Berlin on 8 December 2008, which was covered widely by the Greek media, not to forget a large number of demonstrations and actions all over the world, "motivated" our comrades in Greece not to give up their struggle.
Yes! Antinational Solidarity!
All these cases have one thing in common: they focus on solidarity. But what does solidarity mean, anyway? Today, it turns out to be a largely empty notion with hugely differing meanings; its definition from a left-wing and radical perspective is problematic due to its colloquial, predominant meaning. Bourgeois society understands the principle of solidarity as the selfless duty to serve the "common good", along the lines of "One for all, and all for one". Whether it concerns the shift of the costs of social reproduction back upon the workers via the medium of national insurance, or whether it is about the German government's "Agenda 2010″ or other austerity measures – you can hear the call for "solidarity" play to the tune of national responsibility for state and capital.
Our understanding of "antinational solidarity" is diametrically opposed to this call of duty for the nation. We agree with the concept of solidarity as formulated by the First International: Marx and Engels had derived the basic principle of solidarity from the necessity of the international character of the social revolution. At that time it appeared obvious that only the intention to smash the whole system would enable a general uprising in the spirit of solidarity. We agree and say with Marx: "The revolution must be carried out with solidarity."
Thus, we need to (re)occupy the principle of solidarity and fill it with left-wing and radical content. Solidarity has to be freed from the isolation of single issue campaigns; it has to be revived and updated by purging it of its reactionary and especially if its national blinkers.
We do not want to appear as naïve and overly optimistic in relation to the current struggles. Still, we do find in these time and time again possibilities for theoretical and political radicalisation. However, the struggle for a better life can only succeed if it comes in the form of a social revolution. Until then we see it as our task to disseminate the idea of antinational solidarity beyond the boundaries of Germany and Europe and to continue to criticise and to act against the correlation of state, nation and capital – free from the illusions of the reformist and traditional Left.
For an international antinational movement!
Written by Working Group "Just Do It!" of Antifa AK Cologne, first published in German in February 2012. Republished from Shift magazine


text:
The dog muzzle is made of PVC material and braid, with a mesh design that brings for it practical and durable, helping the dog feel comfortable. The product can effectively prevent dogs from biting, disorderly barking, and indiscriminately chewing and eating. The dog muzzle has a mesh design that is breathable and comfortable, it is specially designed for long mouth dogs. On the other hand, the product helps avoid the dog's unintentional injuries to passers-by.
*Package: Dog Mesh Muzzle X 1
*Size Chart (1cm = 0.394 inches)
Note: There may be 0.5-1"(2-3 cm) errors caused by manual measurement.
Dog Size | Large Dog, Medium Dog, Small Dog |
Material | PVC, Braid |
Here are a few of the frequently asked questions. To provide you with the best customer experience, your feedback is greatly encouraged. If you have any questions please send us an email at email@example.com
Q. How long will it take for my items to arrive?
A. It will usually take 7-14 business days (USA, Canada)/ 10-30 business days (Europe and other countries) for all orders to arrive. Shipping times vary from product-to-product; based on demand and shipping location.
Q. How long will it take to receive a tracking number?
A. It will take usually between 2-5 business days.
Q. Where can I place an order from?
A. You can place an order from any country, we ship Worldwide.
Q. Is shipping really FREE?
A. Yes, shipping is Free Worldwide on most items. One some items, we have Free Shipping over $75.
Q. Which currency will I be charged in?
A. We processes all orders in USD. While the content of the cart is displayed in several currencies, you will checkout using USD at the most current exchange rate.
Q. Will I receive a confirmation number when I place my order?
A. Yes, all customers will receive an order number after placing their orders.
Please contact us if you don't receive one within 24 hours.
Q. Who can I contact if I have a problem with my order?
A. All inquiries can be forwarded to email@example.com
Q. How can I pay?
A. We accept all Major Credit Cards: Visa, Mastercard, Discover, Amex and also Paypal
Q. Is Checkout on this site safe and secure?
A. You can be absolutely sure that all purchases here are safe and secure.
Q. If I enter my email address will you sell my information?
A. We do not sell our customers information. Emails are strictly for follow-up and to send newsletters of our promotions and coupons for discounts.
Q. Will I (the customer) have to pay customs?
A. For most countries, you will not have to pay customs, but it depends where are you located and if you order more than 1 piece.
We ship worldwide! It may take 2-5 days for your order to be wrap up and ship from our facility. And 5-14 business days for our product to reach there destination ( USA, Canada ), Europe and other countries may take 7-25 business days for your item to delivered to your house.


text: Subscribe | UPI Odd Newsletter Subscribe Come January, it will be 10 years since trumpeter Dizzy Gillespie lost his battle against cancer. It ended a distinguished and innovative career for one of the true geniuses of jazz. But his impact on the music -- and the people who worked with him -- lives on. That impact -- as writer, arranger, bandleader and human being -- is so powerful that some still feel his presence, as if he's looking over their shoulders. Advertisement Gillespie's legacy was the subject of a discussion by eight musicians who played with him at various stages of his career. They shared their thoughts at a panel discussion last month at the Cape May (N.J.) Jazz Festival. The weekend of music was a Gillespie tribute. "For me, the most important part of Dizzy's persona was that he was always searching; he was always listening to music from all over," said flutist Herbie Mann. "We had grown up listening to Bird (Charlie Parker) and bebop, but all of a sudden this other element came into the music and he was the first guy to do that. Advertisement "There was no flute tradition in jazz," Mann said. But I said 'Wait a minute, in other cultures, the flute is one of the improvisers -- in Cuban music, Brazilian music, African music. That became my path. Dizzy was the one to open up that path and I am eternally grateful." Tenor saxophonist Benny Golson recalled when he joined Gillespie's band in 1956 and visited the rehearsal studio that Dizzy had in the basement of his home, then in the Corona section of Queens, N.Y. "It was like being greased with oil from a holy man. Everything he shared with me I remember. I started to play my horn and played the bridge to "Woody 'N' You." He said, 'Uh, uh, uh, uh.' Like it was painful to him. I was playing it wrong," Golson said. "I was playing it the way everyone else had. But he said it was wrong and he showed me the correct way. Dizzy was a man who shared everything he knew. He had no secrets. He was a master with rhythms. He just had a knack for the rhythm." Alto saxophonist Phil Woods made a separate trip to that same basement - but it wasn't a willing journey --- at first. Advertisement "I remember one time, I got kidnapped by Art Blakey and Dizzy Gillespie," Woods said. "I was working at Birdland. I was drinking too much and unhappy with the band I was playing with and moaning and groaning and all that stuff. "Dizzy and Art took me to Dizzy's pad out in Corona where he lived and said: 'Now what is your problem, man?' I said, 'Oh, man, I'm not ready. I'm a white guy I'm not going to make it in jazz.' And Dizzy said, 'Young man, Charlie Parker did not give this music to any particular race. He gave it to everyone in the world. And if you can hear it, you can have it. You can't steal a gift.' I'll never forget that. "I said, 'Do you think I can make it? Dizzy said 'Yeah, if you'd shape up.' He gave me the confidence. He said, 'You can play, but you've got to get your act together.' "These two giants of our industry taking the time off to talk to this maudlin, honky guy who didn't know which end was up. But they took the time," Woods said. "Dizzy was most supportive, and school was open always to the end. Advertisement "The amazing thing was the yin and yang of Charlie Parker and Dizzy Gillespie. Bird was the meteor who wasn't around a long time. He came, he changed it and he left. But Dizzy was the arranger, the composer, the reader, the sober industrious one. Everybody knew who the boss was," Woods said. "Dizzy was the teacher, the one who passed it on." Pianist Junior Mance called his years in the Gillespie band from 1958 to 1961 "probably my most profound learning experience. I learned more from my three years with Dizzy than all of my music teachers, even in the music school that I dropped out of," Mance said. "I remember spending several hours at a time in his basement studio being shown chord changes that I never knew existed. How to comp, how to accompany instrumentalists ... that to play the right chord changes I had to listen. I learned a lot of little things that weren't in books." Bassist Earl May had experience with acoustic, upright basses before joining Gillespie in 1971-74. But Dizzy forced him to get an electric bass because his music was turning in a funkier direction. "I didn't make sense to me in a bebop context, but it worked out very well," May said. "I went halfway around the world with him and every place we went seemed like his backyard. He had an enormous way of bringing everybody to him." Advertisement "He gave a chance to so many young and old players," says reed player Paquito d'Rivera, whom Gillespie sought out as a teenager in Cuba and was a member of his United Nation Orchestra from 1988 to 1991. Gillespie had arrived in Havana aboard a cruise ship with several other jazz musicians and had heard about d'Rivera's blossoming talent. But when Gillespie knocked on his door, nobody was home. "I found a note in my door that said 'Paquito, we have been looking for you. Where are you?' It was signed 'Dizzy Gillespie.' I said 'What kind of joke is this?' Then I then went to the grocery store on the corner. The owner said, 'Paquito, there was a man looking for you. He is a black guy who dressed like Sherlock Holmes.' I said, 'Ah, Dizzy Gillespie.'" Brazilian trumpeter Claudio Roditi worked alongside d'Rivera in Gillespie's final band. "Dizzy brought humor to the stage always. But I never saw him clown or crack a joke when he put the trumpet to his lips. When he played, it was for real. It was serious," Roditi said. Bassist John Lee was a member of several different Gillespie bands -- large and small -- from 1984 to 1982, and now is program director of the Dizzy Gillespie Alumni All-Stars. Advertisement "I can't decide whether I learned more from him about music or life -- and it was probably the latter," Lee said. "He always had fun every night. We'd travel 16 hours sometimes, but no matter how tedious the travel, when we hit the stage, I never saw him mad or cranky. The man was filled with so much love and he gave so much to all of us. His presence is so huge that it doesn't feel like he's gone." Woods also recalled how Gillespie was a frequent jazz ambassador to foreign continents, bringing his music and humanity on tours organized and financed by the U.S. State Department. He was on one of those trips -- to the Middle East -- as a Gillespie sideman in 1956. "When the U.S. government wanted to put its best foot forward, it sent jazz," Woods said. "I personally feel Dizzy should have been sent a few more times to Iran and Baghdad. We might have avoided a whole lot of trouble. Use music, not guns."


text:
UNC Computer, Marine Scientists Collaborate To Predict Flow Of Toxic Waters From Katrina
- Date:
- September 29, 2005
- Source:
- University of North Carolina at Chapel Hill
- Summary:
- In the immediate wake of Hurricane Katrina, scientists and research centers from across the country came together to generate information on the contaminated floodwaters and offer it to hazardous materials experts and public health officials.
- Share:
CHAPEL HILL -- In the immediate wake of Hurricane Katrina, scientists and research centers from across the country came together to generate information on the contaminated floodwaters and offer it to hazardous materials experts and public health officials.
In a matter of hours, the University of North Carolina at Chapel Hill's Marine Sciences Program and Renaissance Computing Institute (RENCI), together with the National Center for Supercomputing Applications (NCSA), played a key role in that effort by providing rapid-response computing and modeling capability.
Floodwaters containing organic and chemical pollutants such as sewage and oil still cover swaths of Mississippi and Louisiana. To aid cleanup, researchers at the National Oceanic and Atmospheric Administration's (NOAA) Coast Survey Development Laboratory (CSDL), along with UNC faculty, have been developing forecasts that will predict the circulation of those foul waters.
A group of researchers, including Drs. Richard Luettich and Brian Blanton, marine scientists in UNC's College of Arts and Sciences, has developed a three-dimensional computer program that can be used to model water levels and flow. This program, "ADCIRC," is what experts call a hydrodynamic code. Previously, the code was used largely for after-the-fact analyses of coastal circulation, but researchers now believe it can help produce answers during a crisis.
Blanton and Luettich, assistant research professor and professor of marine sciences, respectively, knew that to simulate the required 60 days of water velocity and water surface elevation they would need more computational power then they had at the university. They asked UNC's Dr. Daniel A. Reed for help -- based on their NOAA--funded collaboration with RENCI -- to establish a computational system with Web access for rapid-response forecasting to severe weather.
Reed is Chancellor's Eminent professor and vice chancellor for information technology at UNC. North Carolina's 2005-06 budget includes $5.9 million in new funding for RENCI, a collaboration of UNC, Duke and NC State that is based on the Chapel Hill campus and run by Reed. RENCI is slated to receive $11.8 million in recurring funding thereafter.
"If we had a month to do these runs, we could do them on our desktop computers or on a small cluster, but to do it literally overnight requires some horsepower," Blanton said.
Reed, former director of NCSA, connected Blanton and Leuttich with NCSA, the National Science Foundation-supported supercomputing center located at the University of Illinois at Urbana-Champaign. Using NCSA's Xeon system, a state-of-the-art parallel computer called Tungsten, the researchers were able to complete the required computational runs in about 15 hours, from midnight on Sept. 11 to mid-afternoon on Sept. 12.
"This is a prelude to the capabilities RENCI and the University of North Carolina at Chapel Hill will provide to North Carolina, as we deploy our own large-scale computing infrastructure and continue to build disaster-response collaborations with North Carolina experts," Reed said. "With state support, we are now building world-class capability for interdisciplinary research, technology transfer, economic development and engagement across North Carolina."
Researchers at CSDL, with assistance from Luettich and Blanton, are working to integrate information provided by the computational calculations with NOAA's North American Mesoscale Model, the primary weather forecasting model used by the National Weather Service, to simulate wind speed, direction and other weather factors. Their goal is to provide daily forecasts of coastal circulation and pollutant concentrations in the Katrina-affected region, information that will be vital as cleanup efforts and recovery continue.
The two also have extended their work with RENCI, Reed and colleagues to analyze various aspects of last weekend's Hurricane Rita and its effects in Texas and Louisiana.
"We are trying to be prepared and generate reliable information that the hazardous materials experts will need to have," said CSDL scientist Jesse Feynen. "We're doing that, and we're doing it quickly."
Story Source:
Materials provided by University of North Carolina at Chapel Hill. Note: Content may be edited for style and length.
Cite This Page:


text:
Why Network? Various studies indicate that in order to be successful, whether it is working for a company or managing one's own business, the ability to develop relationships across gender, race, and economic class does determine an individual's success, both professionally and personally.
Read MoreEmployees in office jobs that rely heavily upon technology can often perform their duties from home. For many of us with our hectic life styles "work from home" seems such an ideal solution. It evokes images of freedom and leisure. However there are challenges associated with working from home and this article discusses them.
Read MoreWomen have been plagued by the perfectionism bug for a while now. We want to be the perfect daughter, perfect wife, perfect mother, daughter-in-law, friend, employee..... Are we being realistic?
Read MoreDo you remember your teenage years when your world was filled with dreams, hopes and lots of friends? You swore that nothing would be more important than your ties with the sisterhood and that wherever you went you would make time to connect with them. But life happened after that and here you are juggling a demanding career, marriage, children, in-laws, running a ship-shape household and trying to keep your sanity all the while! Sound familiar? This article gives you the low down in finding some time for yourself as well!
Read MoreThe new Superwoman is ordinary in that she is neither rich nor famous. She is extraordinary in that she tries to be everything to everyone - juggling family life, social life, and commitments outside the home. The new Superwoman 'has it all' by 'doing it all' with superlative standards and ends up feeling overwhelmed, overextended, overworked and under-appreciated. Ever wondered where this term "Superwoman Syndrome" originated? Read on to find out...
Read MoreGirls get better grades at school than boys, and in most developed countries more women than men go to university. However, women still get paid less and few make it to the top of companies, and those that do get to the top level, have to face a lot more opposition than most men. Thankfully, there are things women can do to overcome these stereotypes and prejudices and achieve success
Read More
Striking a balance between work and home is one of the most fundamental prerequisites for leading a happy life. There is no one strategy that we all can use which will help us magically strike a balance between these two aspects of our lives. Here are some suggestions to help find and strike a healthy balance.
Read More


text:
Actress Kelly Preston Dies at 57
A family representative revealed to People that actress Kelly Preston died on July 12 after a "two-year battle with breast cancer." She was only 57 years old.
"Choosing to keep her fight private," their statement read, "she had been undergoing medical treatment for some time, supported by her closest family and friend. She was a bright, beautiful and loving soul who cared deeply about others and who brought life to everything she touched. Her family asks for your understanding of their need for privacy at this time."
Born in Hawaii in 1962, Preston's career in film spanned some 35 years. Her earliest appearances included roles in 1986's Space Camp and 1988's Twins, where she played Arnold Schwarzenegger's love interest. Preston soon became a fixture in big Hollywood movies throughout the 1990s. She was most often cast in comedies, but appeared in dramas as well. Her films from that period include Addicted to Love, Nothing to Lose, Holy Man, and For Love of the Game. Her other notable roles include a superhero mom in the underrated Disney movie Sky High, and Jerry's fiancée in Cameron Crowe's Jerry Maguire.
Preston met John Travolta in 1987 while filming The Experts; they married in 1991. During their relationship, they also made several films together including Battlefield Earth and 2018's Gotti. On Instagram, Travolta wrote of Preston:
"She fought a courageous fight with the love and support of so many. My family and I will forever be grateful to her doctors and nurses at MD Anderson Cancer Center ... I will be taking some time to be there for my children who have lost their mother, so forgive me in advance if you don't hear from us for a while. But please know that I will feel your outpouring of love in the weeks and months ahead as we heal."
Travolta and Preston had three children, Jett, Ella, and Benjamin. (Jett passed away in 2009.). This is just a terrible, sad end for a wonderful screen presence. Preston was only 57, far too young for someone to pass away — much less a mother with young children. Here's Travolta's full Instagram post and comments about Preston:
Gallery — The Best Movies of the Year So Far: