text:
This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2005.
Copyright (C) The Internet Society (2004).
This document contains an initial specification for the Explicit Control Protocol (XCP), an experimental congestion control protocol. XCP is designed to deliver the highest possible end-to-end throughput over a broad range of network infrastructure, including links with very large bandwidth-delay products, which are not well served by the current control algorithms. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular. XCP routers are required to perform a small calculation on congestion state carried in each data packet. XCP routers also periodically recalculate the local parameters required to provide fairness. On the other hand, there is no per-flow congestion state in XCP routers.
1.1 XCP Protocol Overview
2. The Congestion Header
2.1 Header placement
2.2 Congestion Header Formats
2.3 IPsec issues
2.4 NAT, middlebox issues
2.5 MPLS/Tunneling Issues
3. XCP Functions
3.1 End-System Functions
3.1.1 Sending Packets
3.1.2 Processing Feedback at the Receiver
3.1.3 Processing Feedback at the Sender
3.2 Router functions
3.2.1 Calculations Upon Packet Arrival
3.2.2 Calculations Upon Control Interval Timeout
3.2.3 Calculations Upon Packet Departure
3.2.4 The Control Interval
3.2.5 Obtaining the Persistent Queue
4. Unresolved Issues
4.1 XCP With Non-XCP Routers
4.2 XCP as a TCP PEP
4.3 Sharing resources between XCP and TCP
4.4 A Generalized Router Model
4.5 Host back-to-back operation
4.6 Alternate Responses to Packet Loss
4.7 Alternate XCP Data Representations
5. Security Considerations
6. IANA Considerations
7. Acknowledgements
8. References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
The Van Jacobson congestion control algorithms [Jacobson88]Jacobson, V., Congestion Avoidance and Control, August 1988.[RFC2581]Allman, M., Paxson, V. and W. Stevens, TCP Congestion Control, April 1999. are used by the Internet transport protocols TCP [RFC0793]Postel, J., Transmission Control Protocol, September 1981. and SCTP [RFC2960]Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, Stream Control Transmission Protocol, October 2000.. The Jacobson algorithms are fundamental to stable and efficient Internet operation, and they have been highly successful over many orders of magnitude of Internet bandwidth and delay.
However, the Jacobson congestion control algorithms have begun to reach their limits. Gigabit-per-second file transfers, lossy wireless links, and high latency connections are all driving current TCP congestion control outside of its natural operating regime. The resulting performance problems are of great concern for important applications of the network.
The original Jacobson algorithm was a purely end-to-end solution, requiring no congestion-related state in routers. More recent modifications have backed off from this purity. Active queue management (AQM) in routers (e.g., RED) [RFC2309]Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, Recommendations on Queue Management and Congestion Avoidance in the Internet, April 1998. improves performance by keeping queues small, while Explicit Congestion Notification (ECN) [RFC3168]Ramakrishnan, K., Floyd, S. and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, September 2001. passes one bit of congestion information back to senders. These measures do improve performance, but there is a limit to how much can be accomplished without more information from routers. The requirement of extreme scalability together with robustness has been a difficult hurdle to passing more information.
This document concerns the Explicit Control Protocol (XCP) developed by Dina Katabi of MIT [KHR02]Katabi, D., Handley, M. and C. Rohr, Internet Congestion Control for Future High Bandwidth-Delay Product Environments, August 2002.. XCP represents a significant advance in Internet congestion control: it extracts congestion information directly from routers, without any per-flow state. XCP should be able to deliver the highest possible application performance over a broad range of network infrastructure, including extremely high speed and very high delay links that are not well served by the current control algorithms. XCP achieves fairness, maximum link utilization, and efficient use of bandwidth. XCP is novel in separating the efficiency and fairness policies of congestion control, enabling routers to put available capacity to work quickly while conservatively managing the allocation of capacity to flows. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular.
XCP's scalability is built upon the principle of carrying per-flow congestion state in packets. XCP packets carry a congestion header through which the sender requests a desired throughput. Routers make a fair per-flow bandwidth allocation without maintaining any per-flow state. This enables the sender to learn the bottleneck router's allocation to a particular flow in a single round trip.
The gains of XCP come with some pain. XCP is more difficult to deploy than other proposed Internet congestion control improvements, since it requires changes in the routers as well as in end systems. It will be necessary to develop and test XCP with real user traffic and in real environments, to gain experience with real router and host implementations and to collect data on performance. Providing specifications is an important step towards enabling experimentation which, in turn, will lead to deployment. XCP deployment issues will be addressed in more detail in a subsequent version of this document.
This document contains an initial specification of the protocol and algorithms used by XCP, as an experimental protocol. The XCP algorithms defined here are based upon Katabi's SIGCOMM paper [KHR02]Katabi, D., Handley, M. and C. Rohr, Internet Congestion Control for Future High Bandwidth-Delay Product Environments, August 2002., her MIT thesis [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003., and her ns simulation. However, this document includes algorithmic modifications and clarifications that have arisen from early experience with implementing and testing XCP. This document is intended to provide a baseline for further engineering and testing of XCP.
This document is organized as follows. The remainder of Section 1Introduction provides an overview of the XCP protocol, Section 2The Congestion Header discusses the format of the congestion header, Section 3XCP Functions describes the functions occurring in the end-systems and routers, and Section 4Unresolved Issues lists some unresolved issues.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
The participants in the XCP protocol include sender hosts, receiver hosts, and intermediate nodes in which queuing occurs along the path from the sender to the receiver. The intermediate nodes are generally routers, but link-layer switches may also contain packet queues.
XCP supplies feedback from the network to the sender on the maximum rate (throughput) for injecting data into the network. XCP feedback is acquired through the use of a congestion header on each packet that is sent. Routers along the path may update the congestion header as it moves from the sender to the receiver. The receiver copies the network feedback into outbound packets of the same flow. An end-system may function as both a sender and a receiver in the case of a bidirectional flow.
The figure below illustrates four entities participating in XCP. The sender initializes the congestion header, two routers along the way may update it, and the receiver copies the feedback from the network into a returning packet in the same flow.
+----------+ +--------+ +--------+ +----------+ | |------->| Router |---->| Router |------->| | | Sender | +--------+ +--------+ | Receiver | | |<----------------------------------------| | +----------+ +----------+
The congestion header contains four pieces of data:
An XCP-capable router calculates a fair capacity re-allocation for each packet. A flow only recieves this re-allocation from a particular router if that router is the bottleneck for that flow. For XCP, a bottlneck router is defined to be a router that has insufficient capacity to accept a flow's current or desired throughput.
Based on current conditions, an XCP-capable router generates positive or negative feedback that is allocated to each packet and compared to the packet's Delta_Throughput field. Delta_Throughput is reduced if the current value exceeds this calculated feedback allocation. Each XCP-capable router along the path from sender to receiver performs this processing. A packet reaching the receiver therefore contains the minimal feedback allocation from the network, i.e., the capacity reallocation from the bottleneck router.
The receiver copies this value into the Reverse_Feedback field of a returning packet in the same flow (e.g., an ACK or DATA-ACK for TCP) and, in one round-trip, the sender learns the flow's per-packet throughput allocation.
The sender uses the reverse feedback information to adjust its allowed sending rate. For the transport protocol TCP [RFC0793]Postel, J., Transmission Control Protocol, September 1981., for example, this may be accomplished by adjusting the congestion window, or cwnd, that limits the amount of unacknowledged data in the network. (Cwnd is defined for Van Jacobson congestion control in [RFC2581]Allman, M., Paxson, V. and W. Stevens, TCP Congestion Control, April 1999..)
Additionally, it is possible to use XCP's explicit notification of the bottleneck capacity allocation for other types of applications. For example, XCP may be implemented to support multimedia streams over DCCP [I-D.ietf-dccp-spec]Kohler, E., Datagram Congestion Control Protocol (DCCP), October 2003. or other transport protocols.
An XCP-capable router maintains two control algorithms on each output port: a congestion controller and a fairness controller. The congestion controller is responsible for making maximal use of the outbound link while at the same time draining any standing queues. The fairness controller is responsible for fairly allocating bandwidth to flows sharing the link. These two algorithms are executed only periodically, at an interval known as the "control interval". The algorithms defined below set this interval to the RTT averaged across all flows. Further work on choosing an appropriate value for the control interval may be required.
Each port-specific instance of XCP is independent of every other, and references to an "XCP router" should be considered an instance of XCP running on a particular output port.
Actually, it is an oversimplification to say that congestion in routers only appears at output ports. Routers are complex devices which may experience resource contention in many forms and locations. Correctly expressing congestion which doesn't occur at the router output port is a topic for further study. Even so, it is important to correctly identify where the queue will build up in a router. The XCP algorithm will drain a standing queue however it is necessary to measure that queue in order for correct operation. For more discussion of this issue see Section Section 4.4A Generalized Router Model.
More context, analysis, and background can be found in [KHR02]Katabi, D., Handley, M. and C. Rohr, Internet Congestion Control for Future High Bandwidth-Delay Product Environments, August 2002. and [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003..
The congestion control data required for XCP are placed in a new header which is called the Congestion Header.
The Congestion Header is located between the IP and transport headers. This is consistent with the fact that XCP is neither hop-by-hop communication -- as in IP -- nor end-to-end communication -- as in TCP or UDP -- but is rather end-system-to-network communication. It should allow a router to "easily" locate the congestion header on a packet with no IP options.
Other choices were considered for header location. For example, making the Congestion Header a TCP option was suggested. This made sense as the congestion information is related to the transport protocol. However, it requires that routers be aware of the header format for every new transport protocol that might ever use XCP. This seemed like an unreasonable burden to place on the routers and would impede deployment of new transport protocols and/or XCP.
It has also been suggested that the Congestion Header be an IPv4-style option. While this proposal is transport protocol independent, it would generally force XCP packets to take the slow path on non-XCP routers along a path. This could severely impact performance.
The XCP protocol uses protocol number [TBD], assigned by IANA. IP packets containing XCP headers will use this protocol number in the IP header's Protocol field [RFC0791]Postel, J., Internet Protocol, September 1981. to indicate to routers and end-systems that an XCP congestion header follows the IP header.
This section defines the XCP Congestion Header formats. This holds for IPv4; the corresponding header for IPv6 is a subject for further study.
XCP-capable IPv4 packets carry the following Congestion Header:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|Format | Protocol | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta_Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse_Feedback | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version: 4 bits
- This field indicates the version of XCP that is in use. The version of XCP described in this document corresponds to a value of 0x01. Future values will be assigned by IANA (http://www.iana.org). See note in the IANA Considerations section.
- Format: 4 bits
- This field contains a code to indicate the congestion header format. The current format codes are defined below.
|Standard Format
|Minimal Format
| Table 1
- Standard Format
- The standard format includes the Throughput, Delta_Throughput, and RTT fields shown above. This format is used by XCP in data packets flowing from sender to receiver.
- Minimal Format
- The Throughput, Delta_Throughput, and RTT fields are unused and SHOULD be set to zero. A router should not perform any processing on a minimal format header. This format is intended for use in empty ACK packets, to return congestion information from receiver to sender.
Other formats may be defined in the future, to define different representation formats for the Throughput, Delta_Throughput, and/or RTT fields, for example. The corresponding format values format values will be assigned by IANA. See IANA Considerations section below.
- Protocol: 8 bits
- This field indicates the next-level protocol used in the data portion of the packet. The values for various protocols are specified by IANA.
- Length: 8 bits
- This field indicates the length of the congestion header, measured in bytes. Length in this version of XCP will always be 40 bytes, or 0x28.
- unused: 8 bits
- This field is unused and MUST be set to zero in this version of XCP.
- RTT: 32bits
- This field indicates the round-trip time measured by the sender, in milliseconds. This field is an unsigned integer.
- The minimum value expressible in this field is 1 ms (values should be rounded up). A value of zero in the RTT field indicates that the sender does not yet know the round-trip time. The maximum value expressible in this field is 4.3E9ms or approximately 49 days.
- Throughput: 32 bits
- This field indicates the current throughput for the flow, as measured by the sender, in bytes per millisecond.
- Throughput values should be rounded up. The maximum value expressible in this field is 4.3E9 bytes/ms or 32 Tbps, in steps of 1 byte/ms or 8000 bytes/sec.
- Delta_Throughput: 32 bits
- This field indicates the desired or allocated change in throughput. It is set by the sender to indicate the amount by which the sender would like to adjust its throughput, and it may be subsequently reduced by routers along the path (See Section 3.2Router functions). It is measured in bytes per second and is a signed, 2's complement value.
- The minimum throughput change expressible in this field is -17 Gbps. The maximum value expressible in this field is 17 Gbps, in steps of 8 bits per second.
- Reverse_Feedback: 32bits
- This field indicates the value of Delta_Throughput received by the data receiver. The receiver copies the field Delta_Throughput into the Reverse_Feedback field of the next outgoing packet in the same flow. See Section 3.1.2Processing Feedback at the Receiver.
IPsec [RFC2401]Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, November 1998. must be slightly modified to accommodate use of XCP. The specifications for the IP Authenticated Header (AH) [RFC2402]Kent, S. and R. Atkinson, IP Authentication Header, November 1998. and IP Encapsulating Security Payload (ESP) [RFC2406]Kent, S. and R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998. state that the IPsec headers immediately follow the IP header. This would be a problem for XCP in that a) it would make the XCP headers harder to find by the routers, b) ESP encryption would make it impossible for routers along the path to read and write congestion header information and c) AH authentication would fail if any router along the path had modified a congestion header. Therefore, the XCP congestion header should immediately follow the IP header and precede any AH.
Middleboxes that attempt to perform actions invisibly on flows must preserve the congestion header. Middleboxes that terminate the TCP connection should terminate the XCP connection. Middleboxes that insert queues into the forwarding path should participate in XCP.
When a flow enters an IP tunnel [RFC2003]Perkins, C., IP Encapsulation within IP, October 1996., IPsec ESP tunnel [RFC2406]Kent, S. and R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998., or MPLS [RFC3031]Rosen, E., Viswanathan, A. and R. Callon, Multiprotocol Label Switching Architecture, January 2001., network ingress point, the congestion header should be replicated on the "front" of the outer IP header. For example, when a packet enters an IP tunnel, the following transformation should occur:
[IP2] \_ outer header __--> [XCP] / [IP1]/ [IP1] \ [XCP] ---> [XCP] |_ inner header [TCP] [TCP] | ... ... /
Here the XCP header appended to the front of the outer header is copied from the inner header, with the appropriate change to the Protocol field to indicate that the next protocol is IP.
When the packet exits the tunnel, the congestion header, which may have been modified by routers along the tunneled path, is copied from the outer header into the inner header.
XCP is concerned with the sender and receiver end-systems and the routers along the packet's path. This section describes the XCP-related algorithms to be implemented in each of these entities. The specific case of TCP as transport protocol is also described. The emphasis in this section is on explicit and detailed definition of the XCP algorithms. The theoretical derivation and analysis of the algorithms can found in [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003..
The sender is responsible for maintaining four parameters, or their equivalent: (1) a desired throughput value, (2) a current estimate of the actual throughput, (3) the maximum throughput allowed by XCP, and (4) a current estimate of the round-trip time
A sender may choose to use any reasonable value, i.e., any achievable value, for desired throughput. This value may be supplied by an application via an API, or it might be the speed of the local interface.
When sending a packet, the sender fills in the fields of
the congestion header as follows:
The Delta_Throughput (in bytes/second) can be expressed as:
desired_throughput - Throughput*1000 Delta_Throughput = ----------------------------------- Throughput *( RTT/MSS ) where: desired_throughput is measured in bytes/second Throughput is measured in bytes/milliseconds RTT is measured in milliseconds MSS is measured in bytesHowever, Delta_Throughput should be set to zero if, for any reason, no additional capacity is needed, e.g., there is insufficient data to fill one RTT.
An XCP receiver is responsible for copying the Delta_Throughput data it sees on arriving packets into the Reverse_Feedback field of outgoing packets. In TCP, outgoing packets would normally be ACK-only segments.
In some cases returning packets are sent less frequently than arriving packets, e.g., with delayed acknowledgments [RFC1122]Braden, R., Requirements for Internet Hosts - Communication Layers, October 1989.. The receiver is responsible for calculating the sum of the arriving Delta_Throughput fields for placement in outgoing Reverse_Feedback fields.
The receiver end-system returns XCP congestion feedback from the network to the sender, by copying the Delta_Throughput information from arriving packets into the Reverse_Feedback field of Congestion Headers in outgoing packets (possibly aggregating data as described in Section 3.1.2Processing Feedback at the Receiver).
It is possible that even empty ACK packets may create or encounter congestion in the reverse direction. Although TCP implementations are generally not prepared to do any kind of congestion-based pacing of empty ACK segments, some transport protocols (e.g., DCCP) may be. Such a transport protocol may choose to do XCP congestion control on the returning ACKs as well as on the data.
In the normal case of a undirectional data flow with XCP applied only to that data flow, the feedback can be sent in a Minimal format Congestion Header, in which the RTT, Throughput, and Delta_Throughput fields are set to zero.
When packets arrive back to the sender carrying reverse feedback, the sender must adjust its sending rate accordingly.
As noted earlier, this throughput adjustment may be made in TCP by updating the sender's congestion window cwnd. This should use the formula:
cwnd = max(cwnd + feedback * RTT * 1000, MSS) where: cwnd = current congestion window (bytes) feedback = Reverse_Feedback field from received packet, (bytes/sec, may be +/-) RTT = Sender's current round-trip time estimate (ms) MSS = maximum segment size (bytes)
The value of cwnd has a minimum of MSS to avoid the "Silly Window Syndrome" [RFC0813]Clark, D., Window and Acknowledgement Strategy in TCP, July 1982..
When a sending application does not send data fast enough to fully utilize the allowed throughput, XCP should reduce the allowed throughput as time passes, to avoid sudden bursts of data into the network if the application starts to send data later.
We present a slight modification of the algorithm for aging the allowed throughput below. It is based on Section 4.5 of [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003.. Each RTT in which the sender sends with actual throughput which is less than the allowed throughput, the allowed throughput MUST be reduced by the following exponential averaging formula:
Allowed_Throughput = Allowed_Throughput*(1-p) + Actual_Throughput * p where: p is a parameter controlling the speed of aging, ranged between 0 and 1.
Using p = 0.5 is suggested. Consideration of values of p or other algorithms is a research topic.
When the transport protocol is TCP, a packet drop or detection of an ECN notification [RFC3168]Ramakrishnan, K., Floyd, S. and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, September 2001. should trigger a transition to standard TCP congestion control behavior[RFC2581]Allman, M., Paxson, V. and W. Stevens, TCP Congestion Control, April 1999.. In other words, cwnd should be halved and Jacobson's fast retransmission/fast recovery, slow start, and congestion avoidance algorithms should be applied for the remainder of the connection. The assumption is that the packet drop reveals the presence of a congested non-XCP router in the path. Transitioning to standard TCP behavior is a conservative response.
Note also the following:
Having a good estimate of the round trip time is more important in XCP than in Van Jacobson congestion control. There has been some experimental evidence that small errors in the RTT estimate can result in larger errors in the throughput value. The current cwnd divided by SRTT is only an approximation of the actual throughput. The RTT used in the ns-2 code in [KHR02]Katabi, D., Handley, M. and C. Rohr, Internet Congestion Control for Future High Bandwidth-Delay Product Environments, August 2002. used a smoothed RTT estimator, rather than instantaneous measurements. Additional research is needed to develop recommendations for RTT estimation.
The router calculations for XCP are divided into those that occur upon packet arrival, those that occur upon control interval timeout, those that occur upon packet departure, and the assessment of the persistent queue, which uses a separate timer. The calculations are presented in the following sections as annotated pseudocode.
When a packet arrives at a router, several parameters used by XCP need to be updated. The steps are described in the following pseudocode.
======================================================== On packet arrival do: 1. input_traffic += Pkt_size 2. sum_inv_throughput += Pkt_size / Throughput 3. if (Rtt < MAX_INTERVAL) then 4. sum_rtt_by_throughput += Rtt x Pkt_size / Throughput 5. else 6. sum_rtt_by_throughput += MAX_INTERVAL x Pkt_ size / Throughput ========================================================
- Line 1:
- The variable input_traffic accumulates the volume of data that have arrived during a control interval. When a packet arrives, the packet size is taken from the IP header and is added to the ongoing count.
- Line 2:
- The variable sum_inv_throughput is used in the control interval calculation (see equation 4.2 of [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003. and in capacity allocation. For each packet, the ratio of packet size (from the IP header) to advertised Throughput (from the XCP header) is accumulated.
- Lines 3 and 5:
- A test is performed to check whether the round trip time of the flow does exceeds the maximum allowable control interval. If so, MAX_INTERVAL, the maximum allowable control interval, is used in the subsequent calculations. Too large a control interval will delay new flows from acquiring their fair allocation of capacity.
- Lines 4 and 6:
- As in Line 2, the variable sum_rtt_by_throughput is used in the control interval calculation.
When the control timer expires, several variables need to be updated as shown below.
======================================================== On estimation-control timeout do: 7. avg_rtt = sum_rtt_by_throughput / sum_inv_throughput 8. input_bw = input_traffic / ctl_interval 9. F = a * (capacity - input_bw) - b * queue / avg_rtt 10. shuffled_traffic = shuffle_function(...) 11. residue_pos_fbk = shuffled_traffic + max(F,0) 12. residue_neg_fbk = shuffled_traffic + max(-F,0) 13. Cp = residue_pos_fbk / sum_inv_throughput 14. Cn = residue_neg_fbk / input_traffic 15. input_traffic = 0 16. sum_inv_throughput = 0 17. sum_rtt_by_throughput = 0 18. ctl_interval = max(avg_rtt, MIN_INTERVAL) 19. timer.reschedule(ctl_interval) ========================================================
- Line 7:
- Update avg_rtt by taking the ratio of the two sums maintained in the previous section. This value is used to determine the control interval below (line 17).
- Line 8:
- The average bandwidth of arriving traffic is calculated by dividing the bytes received in the previous control interval by the duration of the previous control interval.
- Line 9:
- The aggregate feedback, F, is calculated. The variable `capacity' is the ability of the outbound link to carry IP packets, in bytes/second. The variable avg_rtt was calculated in line 7. The variable queue is the persistent queue and is defined in section Section 3.2.5Obtaining the Persistent Queue. The values a and b are constant parameters. The constant a may be any positive number such that a < (pi/4*sqrt(2)). A nominal value of 0.4 is recommended. The constant b is defined to be b = a^2*sqrt(2). (If the nominal value of a is used, the value for b would be 0.226.) Note that F may be positive or negative.
- Line 10:
- This line establishes the amount of capacity that will be shuffled in the next control interval through the use of the shuffle_function. Shuffling takes a small amount of the available capacity and redistributes it by adding it to both the positive and negative feedback pools. This allows new flows to acquire capacity in a full loaded system.
- The recommended shuffle_function is as follows:shuffled_traffic = max(0, 0.1 * input_bw - |F|)
- The variable input_bw is defined above in Line 8. Implementors may choose other functions. It is important to consider that more shuffled traffic decreases the time for new flows to acquire capacity and converge to fairness. Too much shuffling may impede flows from acquiring their fair share of available capacity. (For example, consider a setup of N flows bottlenecked downstream from the given router and another flow, not limited as those, trying to acquire its fair share. In this case shuffling leads to under-utilization of the available bandwidth and impedes the unlimited flow.) Shuffled_traffic is always a positive value.
The objective of the feedback calculations is to obtain a per-packet feedback allocation from the router. Lines 13 and 14 obtain factors in this calculation, which, however, have no physical meaning. One might view them as per-flow capacity allocations that have some additional processing to prepare them for per-packet allocation. Note that, with the use of shuffled_traffic, a non-idle router will always start a control interval with non-zero values for both Cn and Cp.
- Line 11:
- This line calculates the positive feedback scale factor, Cp. The variables F, shuffled_traffic, and sum_inv_throughput are defined above.
- Line 12:
- This line calculates the negative feedback scale factor, Cn. This is a positive value. The definitions for F, shuffled_traffic, and input_traffic are given above.
- Line 13:
- The variable residue_pos_fbk keeps track of the pool of available positive capacity a router has to allocate. It is initialized to the positive aggregate feedback.
- Line 14:
- The variable residue_neg_fbk keeps track of the pool of available negative capacity a router has to allocate. It is initialized to the negative aggregate feedback. This variable is always positive.
- Line 15-17:
- Reset various counters for the next control interval.
- Line 18:
- Set the next control interval. The use of MIN_INTERVAL is important to establish a reasonable control interval when the router is idle.
- Line 19:
- Set timer.
An XCP router processes each packet using the feedback parameters calculated above. As stated earlier, each packet indicates the current Throughput and a throughput adjustment, Delta_Throughput. The router calculates a per-packet capacity change which will be compared to the Delta_Throughput field in the packet header. Using the AIMD rule, positive feedback is applied equally per-flow, while negative feedback is made proportional to each flow's capacity.
To accommodate high-speed routers, XCP uses a fixed-point numeric representation for the Congestion Header fields. This means that the per-packet calculations defined below result in some residual error < 1 Bps. These errors accumulate across all the packets in a control interval, resulting in an inaccuracy in XCP's allocation of available bandwidth to flows. Further work is needed to understand whether this will be a significant problem and, if so, whether there is any solution short of using 64 bit precision or floating point.
Processing should be done according to the pseudocode below.
======================================================== On packet departure: 20. pos_fbk = Cp * Pkt_size / Throughput 21. neg_fbk = Cn * Pkt_size 22. feedback = pos_fbk - neg_fbk 23. if(Delta_Throughput > feedback) then 24. Delta_Throughput = feedback 25. else 26. neg_fbk = min(residue_neg_fbk, neg_fbk + (feedback - Delta_Throughput)) 27. pos_fbk = Delta_Throughput + neg_fbk 28. residue_pos_fbk = max(0, residue_pos_fbk - pos_fbk) 29. residue_neg_fbk = max(0, residue_neg_fbk - neg_fbk) 30. if (residue_pos_fbk <= 0) then Cp = 0 31. if (residue_neg_fbk <= 0) then Cn = 0 ========================================================
- Line 20:
- The contribution of positive feedback for the current packet is calculated using Cp, defined in line 13, Pkt_size from the IP header, and Throughput (the flow's advertised throughput) also from the Congestion Header.
- Line 21:
- The contribution of negative feedback for the current packet is calculated using Cn, defined in line 14, and Pkt_size from the IP header. This value of neg_fbk is positive.
- Line 22:
- The router's allocated feedback for the packet is the positive per-packet feedback minus the negative per-packet feedback. This value may be positive or negative.
- Line 23-24:
- Line 23 tests whether the packet is requesting more capacity (via the packet's Delta_Throughput field) than the router has allocated. If so, this means the the sender's desired throughput needs to be reduced to be the router's allocation. In line 24 the Delta_Throughput field in the packet header updated with the router feedback allocation.
- Line 25:
- This branch is executed when the packet is requesting less throughput than the router's allocation. In this branch, and the rest of this pseudocode, the packet header is not updated and the remaining code is to correctly update the feedback pool variables.
- Line 26:
- In this line, the packets negative feedback contribution, neg_fbk, is set to be the smaller of two terms. The first term, residue_neg_fbk, is the pool of negative feedback, i.e., this drains the remaining negative feedback in the pool. The second term increases the nominal negative feedback from the router by the amount which the Delta_Throughput is less than net router allocation. This allows the router to capture feedback which is allocated by an upstream bottleneck.
- Line 27:
- The positive allocation, pos_fbk, is adjusted to be the sum of Delta_Throughput and neg_fbk, from Line 26. This is required for the sum of pos_fbk and neg_fbk to equal Delta_Throughput.
- Line 28-29:
- In these two lines, the feedback pools, residue_pos_fbk and residue_neg_fbk, are reduced by the values of pos_fbk and neg_fbk accordingly, but prevented from going negative.
- Line 30-31:
- When a feedback pool becomes empty, set the scale factor to zero, i.e., stop handing out associated feedback.
The capacity allocation algorithm in XCP router updates several parameters every Control Interval. The Control Interval is currently defined to be the average RTT of the flows passing through the router, i.e., avg_rtt calculated in Line 7 above. Other possible choices for the control interval are under study.
Notes on avg_rtt:
In Section 3.2.2Calculations Upon Control Interval Timeout the variable 'queue' contains the persistent queue over the control interval. This is intended to be the minimum standing queue over the (queue estimation) interval.
The following pseudocode describes how to obtain the minimum persistent queue:
======================================================== On packet departure do: 32. min_queue = min(min_queue, inst_queue) ======================================================== When the queue-computation timer expires do: 33. queue = min_queue 34. min_queue = inst_queue 35. Tq = max(ALLOWED_QUEUE, (avg_rtt - inst_queue/capacity)/2) 36. queue_timer.reschedule(Tq) ========================================================
- Line 32:
- The current instantaneous queue length is checked each time a packet departs compute the minimum queue size.
If avg_rtt is being used as the Control Interval, it MUST NOT be used as the interval for measuring the minimum persistent queue. Doing so can result in a feed-forward loop. For example, if a queue develops the average RTT will increase. If the avg_rtt increases, it takes longer to react to the growing queue and the queue gets larger, leading to instability.
- Line 33:
- Upon expiration of the queue estimation timer, Tq, the variable queue, the persistent queue, is set to be the minimum queue occupancy over the last Tq.
- Line 34:
- Upon expiration of the queue estimation timer, reset the running estimate of the minimum queue to be the current queue occupancy.
- Line 35:
- The first term in the max function, ALLOWED_QUEUE, is the standing queue size that you are willing to maintain. (A nominal value of 2ms worth of queuing is recommended but this may be tuned by implementors.) The second term is an estimate of the propagation delay. In other words the persistent queue is a queue that does not drain in a propagation delay. the division by 2 is a conservative factor to avoid overestimating the propagation delay.
- Line 36:
- The queue computation timer is set.
This section will be expanded to include more detailed text on the topics below.
Non-XCP routers will exist in networks before XCP becomes commonly deployed and we expect other non-XCP systems to continue to be in the network indefinitely. Long term non-XCP network elements include any sort of link-level switches with queueing, e.g. ATM switches and sophisticated Ethernet switches. Even simple multiplexors are non-XCP queues with very little buffering.
Sources and the network care about these non-XCP elements because any one of them can be a site of network congestion, and if an XCP endpoint is bottlenecked at one of these non-XCP elements, no router feedback will inform the endpoint to slow down. If nothing is done, such an element will probably collapse under congestion.
Although exactly how XCP sources will operate in this environment is an open issue, a current promising direction is for endpoints to run a traditional end-to-end congestion detection algorithm in parallel with the XCP algorithm and switch over to using that algorithm for control when congestion is detected that XCP is not controlling. For example, an XCP source that detects 3 duplicate acknowledgments would fall back to TCP Reno behavior.
An endpoint that is limited by its end-to-end congestion algorithm would indicate so to XCP routers by setting a bit in the packet header. A router may process such packets differently from packets from endpoints that are being controlled by XCP. For example, the router might allocate end-to-end controlled packets less feedback or not reduce its feedback pools by the full amount when assigning feedback to those packets.
Though using its end-to-end algorithm to control its sending rate, an endpoint will also monitor the XCP feedback and if the source discovers that the XCP feedback would be more restrictive than the end-to-end control over a round trip time, the endpoint will revert to following XCP feedback. XCP feedback that is more restrictive over a round trip time is an indication that the endpoint's bottleneck is once again at an XCP router and the endpoint should take advantage of the more precise XCP information.
Evaluation of these algorithms is ongoing work
In the Internet today TCP performance-enhancing proxies (PEPs) are sometimes used to improve application performance over certain networks. TCP PEPs, and the issues surrounding their use are described in [RFC3135]Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations, June 2001.. A common mechanism used in TCP PEPs is to split a TCP connection into three parts where the first and last run TCP and a more aggressive transport protocol is run in the middle (across the path which generates poor TCP performance). This improves performance over the "problematic" portion of the path and does not require changing the protocol stacks on the end systems. For example, if a high-speed satellite link was used to connect a LAN to the Internet, a TCP PEP may be placed on either side of the satellite link.
It is not unusual today to find TCP PEPs which, to get high data rates, do not use congestion control at all. Of course, this limits the environments in which they can be used. However, XCP may be used in between two TCP PEPs to get high transfer rates and still respond to congestion in a correct and scalable way.
Work on using XCP as a TCP PEP is just beginning. Objectives for such a mechanism would be:
A system which met the above objectives could also be used for incremental deployment of XCP. A network operator could deploy XCP-capable routers and use PEPs at the periphery of the network to convert from traditional TCP to XCP congestion control. This may result in smaller queues and improved link utilization within the XCP network. (This may be of more interest to wireless network providers than to over-provisioned fiber backbones.)
Katabi describes a system for sharing router bandwidth between XCP and TCP flows that is based on sharing the output capacity based on the average throughputs of XCP and TCP sources using the router.[Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003. Two queues are installed at the router and they are served with different weights by the forwarding engine. The algorithm is work-conserving; the forwarding engine is never idle when either queue has packets in it.
A TFRC-like algorithm estimates the average congestion window of TCP sources and the XCP algorithm estimates the average throughput of XCP sources. These averages are used to dynamically weight the time the processor spends on each queue. Initial experiments indicate that this system can provide fairness between the two flow classes (XCP/TCP).[Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003.
Open issues remain, however; for example there are questions about how well the TFRC-like algorithm can estimate TCP throughput with only access to local drop rates, convergence time of the weighting algorithm has never been explored, and no system for buffer allocation to complement the link capacity allocation has been put forward. These open issues are under study.
The XCP algorithm described here and in [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003. manages congestion at a single point in a router, most likely an output queue. However, resource contention can occur at many points in a router. Input queues, backplanes, computational resources can 'congest' in addition to output buffers. There is a need to develop a general model and a variety of mechanisms to identify and manage resource contention throughout the router.
XCP hosts should be capable of back-to-back operation, i.e., with no router in the path. Nominally, this should not be a problem. A sender initializes delta_throughput to the desired value, no router modifies it and, thus, it is automatically granted. However, it has not yet been decided whether an XCP receiver should be capable of (or require) adjusting the delta_throughput to request flow control from the receiver to the sender.
At this point, XCP offers no mechanism for flow control. (Open question: Should it?) It is believed that running XCP on the output queue of a host would solve this problem. However, it isn't clear that the complexity is justified by the need to solve this situation.
The correct response by an XCP end-system when faced with a packet drop is a research question. The solution sketched out in Section 184.108.40.206Response to Packet Loss is fairly conservative, and other solutions have been suggested. [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003. proposed the use of recent drops to estimate a TCP fair rate, as described in [Padhye98]Padhye, J., Firoiu, V., Towsley, D. and J. Krusoe, Modeling TCP throughput: A simple model and its empirical validation, 1998.. Another suggestion has been made to observe Van Jacobson-style behavior for one RTT following a drop, then return to XCP behavior.
Alternative representations of Congestion Header values may further reduce router processing. In particular, the divisions are hard and should be done at the sender if possible. Katabi has noted that the Throughput value in the Congestion Header is actually used only as the denominator of Pkt_size/Throughput (see Lines 2 and 20 above). Thus, the divisions performed on every packet can be eliminated by sending the ratio Pkt_size/Throughput, rather than Throughput, in the Congestion Header. Further research is in progress on this possibility.
The presence of a header which may be read and written by entities not participating in the end-to-end communication opens some potential security vulnerabilities. This section describes them and tries to give enough context so that users can understand the risks.
- Man-in-the-Middle Attacks
- There is a man-in-the-middle attack where a malicious user can force a sender to stop sending by inserting negative feedback into flow. This is little different from a malicious user discarding packets belonging to a flow using VJ congestion control or setting ECN bits. One question worth investigating further is whether the XCP attack is harder to diagnose.
- Covert Data Channels
- IPsec needs to be modified, as discussed in Section 2.3IPsec issues, to allow routers to read the entire congestion header and write the delta_feedback field. This could become a covert data-channel, i.e., a way in which an end-system can make data viewable to observers in the network, on a compromised end-system.
- Malicious Sources
- The XCP algorithms rely on senders to advertise invormation about their current RTT and Throughput and correctly respond to feedback delivered from the network. Naturally, the possibility occurs that a sender won't perform these functions correctly. Chapter 7 of [Katabi03]Katabi, D., Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks, March 2003. and [Katabi04]Katabi, D., XCP's Performance in the Presence of Malicious Flows, February 2004. examine these issues.
- A source which lies about its throughput cannot affect the link utilization and, in the worst case, can unfairly acquire capacity. However, this is equivalent to a sender opening up multiple TCP flows. So, there is an incentive to lie about throughput. However, because throughput is explicitly stated in each packet header, it is a simpler matter to police it at the edge of the network than, say, for TCP.
- A source which lies about its RTT can disrupt the router control algorithm, particularly when a large number of sources lie about their RTT and the router control interval is adaptive and uses the average RTT. However, there is little incentive to lie as it will not affect the fair allocation of capacity and the liar will experience the same degradation as the non-lying flows. Lying about RTT should be considered a weak denial-of-service attack.
- A flow may also ignore negative feedback from the router. Such a flow can obtain unfair throughput in a congested router. However, as with lying, the explicit nature of XCP makes it possible to verify that flows are responding to feedback. For example, a policing function in the path (presumeably near the edge so that the load is manageable and it can be expected to see packet flow in both directions) may inspect congestion headers for a flow in both directions. If the policer sees negative feedback heading towards a source and no reduction in throughput it may, e.g., punish the flow by severely restricting the throughput. Note that this can be applied on a probablistic basis, sampling flows only occasionally.
XCP requires the assignment of an IP protocol number. Once this value has been assigned, the number may be inserted (by the RFC Editor) into Section 2.1Header placement and this paragraph may be removed prior to publication.
The authors would like to acknowledge the many contributors who have assisted in this work. Bob Braden applied his usual sage guidance to the project and to the spec, in particular. Ted Faber wrote the initial implementation framework and provided much wisdom on kernel development and congestion control. Yuri Pryadkin performed significant analysis on the algorithm and developed much of the code. John Wroclawski advised on project priorities and strategy. Eric Coe developed the initial implementation and testbed. Aman Kapoor performed supporting simulations and debugged kernel code. Padma Haldar ported ns-2 simulation code to ns-2 distribution. Jasmeet Bagga and Anuraag Mittal conducted simulations on various aspects of XCP performance. On the XCP mailing list, Tim Shepherd, Tom Henderson, and Matt Mathis made valuable contributions to the effort. To all the above go our sincere thanks.
|Kohler, E., "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-05 (work in progress), October 2003 (TXT, PS).
|Jacobson, V., "Congestion Avoidance and Control", ACM Computer Communication Review Proceedings of the Sigcomm '88 Symposium, August 1988.
|Katabi, D., Handley, M. and C. Rohr, "Internet Congestion Control for Future High Bandwidth-Delay Product Environments", ACM Computer Communication Review Proceedings of the Sigcomm '02 Symposium, August 2002.
|Katabi, D., "Decoupling Congestion Control and Bandwidth Allocation Policy With Application to High Bandwidth-Delay Product Networks", MIT PhD. Thesis, March 2003.
|Katabi, D., "XCP's Performance in the Presence of Malicious Flows", Second International Workshop on Protocols for Fast Long-Distance Networks, Presentation, February 2004.
|Padhye, J., Firoiu, V., Towsley, D. and J. Krusoe, "Modeling TCP throughput: A simple model and its empirical validation", ACM SIGCOMM '98 conference on Applications,technologies, architectures, and protocols for computer communication, 1998.
|Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
|Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
|Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
|Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
|Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 (HTML, XML).
|Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (HTML, XML).
|Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998 (HTML, XML).
|Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 (HTML, XML).
|Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 (HTML, XML).
|Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 (HTML, XML).
|Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
|Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
|Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
|Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
|Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
|Aaron Falk
|USC Information Sciences Institute
|4676 Admiralty Way
|Suite 1001
|Marina Del Rey, CA 90292
|Dina Katabi
|Massachusetts Institute of Technology
|200 Technology Square
|Cambridge, MA 02139
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.


text: We regret that an error occurred in the March 2012 issue of SAMJ. The citation in the abstract of the article 'Dyer SJ, Kruger TF. Assisted reproductive technology in South Africa: First results generated from the South African Register of Assisted Reproductive Techniques' should have read 'S Afr Med J 2012;102:167-170.' The online version was corrected on 11 May 2012.

subset: commoncrawl


text:
Pasteur Street Brewing Company (PSBC) brews American style craft beer using the highest quality ingredients from Vietnam & around the world. Using American hops, European Malt, & exotic Vietnamese Ingredients, PSBC creates award-winning beer in Saigon, Vietnam. Look for the Pasteur Street beer sign outside the best bars, restaurants, & hotels in Vietnam.
Fruit & Floral with Jasmine
Clear & Gold Color
Hop Forward with Citrus Notes
Lasting Clean
Passion fruit
Opaque Straw
Tangy Passion Fruit
Crisp and Light
Chocolate Malt
Deep Black
Dark Chocolate w/ Hints of Vanilla & Cinnamon
Lasting Smooth
Spicy with Citrus and Black Pepper
Opaque Straw
Spicy with Slight Fruity Notes
Dry and Effervescent
Light Roasted Coffee Beans
Dark Chestnut Brown
Robust Coffee
Dry and Smooth
We have been fortunate to be featured in some great publications. Feel free to check out some of the articles below. If you are a writer and are looking to do a piece that features Pasteur Street, we'd love to speak with you about our beer. Just email us at email@example.com with the subject 'Press Inquiry' and someone will get back to you ASAP.


text:
AT&T Plans to Sell Linear TV Programmatically
Through partnership with Videology, brands will be able to use software and data to place TV ads
AT&T Inc. T -0.25% says marketers will soon be able to buy ads on linear TV in 26 million homes using Web-like software and data targeting.
Through a partnership with the ad technology firm Videology, AT&T plans to introduce what it's referring to as a "private marketplace" for a select group of advertisers. Using Videology's programmatic ad buying software, these advertisers will be able to buy linear TV ads on a wide range of cable networks in households that subscribe to AT&T's U-Verse service or DirecTV, starting in the third quarter. AT&T acquired DirecTV last year for $49 billion.
Advertisers who buy ads in the AT&T private marketplace will be able to use their own data, as well as data from various third parties, and log onto a self-serve Web interface. There, they'll be able to purchase ads on networks that are more likely to reach specific target audiences, such as people who are likely to be in the market for a new car in the next few months, said Jason Brown, vice president of national advertising sales at AT&T AdWorks.
AT&T is planning a beta test with one advertiser to try out the product over the next few months.
The concept of making TV advertising work more like digital advertising, or "programmatic TV," has moved fairly slowly over the past few years, despite a fair amount of hype.
NBCUniversal announced last week that it would begin selling some national TV ads using automated tools and data.
Like NBCU's move into this sector, the AT&T/Videology partnership helps bring more automation and precision to TV ad selling, but on the back end will still operate fairly manually. Unlike many digital ads, which are delivered to people in milliseconds and targeted to them based on their Web surfing history, the AT&T TV ads will still be placed within shows ahead of time, and advertisers will need to book ad space in advance.
A big selling point for AT&T in this venture will be the promise of transparency, Mr. Brown said.
"What we've heard in the marketplace [regarding other "programmatic TV" offerings] is that you don't know where your ads are going to run and there is limited access to quality ad inventory," he said. "This solves for both of these things."
While this new private marketplace is focused on linear TV, Mr. Brown said that down the road AT&T will explore expanding this capability to the company's just announced mobile-focused products. On Tuesday AT&T revealed plans to offer DirecTV subscriptions to mobile consumers as well as a separate ad-supported streaming service.
But for now, the big opportunity is in going after national advertisers' traditional TV budgets, while also satisfying their desire to borrow some of digital advertising's targeting capabilities.
"What is unique about this is that we're talking about premium, reserved, upfront and scatter-based TV ad inventory," said Videology Chief Executive Scott Ferber. "That's very different than what's been available historically. This is aimed at 99% of the ad money that is out there."
Write to Mike Shields at email@example.com
Copyright ©2020 Dow Jones & Company, Inc. All Rights Reserved. 87990cbe856818d5eddac44c7b1cdeb8
CONTENT FROM OUR SPONSORDeloitte
CMO Insights and Analysis from Deloitte
Back-to-School Shoppers Juggle Anxiety, Uncertainty
Concern about health, finances, and the quality of education this spring has increased consumer anxiety and is changing traditional back-to-school shopping behavior. Many parents are shifting spending to tech and electronic gadgets to address the new realities of remote learning.
Please note: The Wall Street Journal News Department was not involved in the creation of the content above.More from Deloitte


text:
Today, personal communication is greatly enabled and enhanced by various messaging apps that provide text messaging, voice calls, photo sharing, and even video chat. These apps are often found in smartphones —devices that have all the features of a desktop computer, plus Wi-Fi, cellular, GPS, and data connectivity.
Cybercriminals have taken advantage of the convergence of the power of the smartphone and the features of chat apps to lure victims into compromising situations and blackmail them. Trend Micro's latest paper, Sextortion in the Far East, talks about the latest developments concerning online blackmail.
Sextortion is a form of online blackmail involving persuading a victim into performing sexual acts that are secretly recorded. The attacker then forces the victim to give in to the attacker's demands by threatening to release the previously recorded acts publicly.
Figure 1. Comparison of old sextortion scheme to the new one
Techniques as above have changed in the modus operandi, and cybercriminals are now asking for money as payment in lieu of sexual favors.
Data Stealers
The Android data stealer's primary purpose is to retrieve and send victims' contact lists to the cybercriminals, allowing them to make more effective threats. Trend Micro's investigation revealed the use of four Android data stealer families for sextortion with each of the four variants containing aggressive techniques. They were able to intercept and log the victims' incoming text message and even prevent victims from receiving calls.
Sextortion in the Far East and Beyond
In-depth investigation on various sextortion scams led to developers in China tasked to create malicious apps and sites using Chinese and Korean. However, the incidents weren't limited to these countries but extended to Japan as well. Sextortion cases have also been spotted in other parts of the world. There have been reports in Canada, the UK, and the US.
For the LATEST tech updates,
FOLLOW us on our Twitter
LIKE us on our FaceBook
SUBSCRIBE to us on our YouTube Channel!


text:
Fall is right around the corner, and that means a few things. First, pumpkin spice is going to start creeping its way back onto menus everywhere. Second, back-to-school blues are striking students across the nation. Third, a cool breeze is beginning to become present during the day and is definitely sneaking its way into our nights. Overall, the temperature is dropping and coziness is becoming paramount.
A huge part of preparing for fall is a fall wardrobe. Something between the light layers of summer and the bulky coats of winter sits a category of clothing that will keep you warm, but not hot. The items listed below will help you to transition your style from summer to fall before you have to completely cover up for winter. Alternatively, if you're traveling to somewhere a little cooler, these pieces are sure to keep you comfortable without adding bulkiness.
So grab some hot cider, start thinking about your Halloween costume, and bundle up in the clothing items listed below.
Fall Travel Wear For Women:
This is a great piece to throw in your car or workbag. If a warm autumn day turns into a chilly afternoon or cold night, then you can use this layer to truly transform a warm outfit into something more appropriate for cool weather.
Fall Travel Wear For Women:
The block coloring and cheeky cat design mean that they are meant to be visible, so there is no need for your ankles to suffer in the face of fashion. The wool these are made up is super soft, breathable, and durable, and will keep your feet comfortable and warm all day long! So pick up a pack of these adorable socks and make a statement with them.
Fall Travel Wear For Women:
These tights come in 13 neutral colors – from white to black, so you can choose whatever base color works for you. When the temperature drops there is no need to ditch your favorite dresses, skirts, and shorts, just layer them up with these tights and keep wearing them!
Fall Travel Wear For Women:
This sweater has a hood, a classic button closure, and a warm and fuzzy lining that will make you feel like you are wearing your pajamas out in public. It comes in five neutral colors, which means you can layer it on top of pretty much anything. With two large pockets, you can carry pretty much anything with you. So grab this sweater and never shiver again!
Fall Travel Wear For Women:
Not as cool as a sandal or loafer, but not as stifling as a riding or snow boot, these classic little booties scream fall. The body is leather and the sole is rubber, and they come in an astounding 40 color and pattern options. Pick up a pair of these boots to pair with skirts, dresses, or jeans, and you will feel warm without being hot.
Fall Travel Wear For Women:
The classic style and color will make you think cozy thoughts, whether you are enjoying some hot chocolate on a porch or enjoying some cheese and wine in the great outdoors. Woolrich is a trusted brand that makes great products, so it is hard to go wrong with one of their blankets. It is a heavy, warm fall blanket that can turn nearly any situation into a cozy fall moment. Once you own it you will wonder how you ever went without it!
Fall Travel Wear For Women
Don't despair when the temperature starts to lower. Instead, enjoy the warm sunshine, the cool breeze, and the chilly nights with your brand new fall wardrobe. You don't have to stick to a hoodie (though we understand if you'd want to). With these items, you will look good, feel great, and definitely be prepared for anything autumn throws at you!


text:
Society today is very focused on sustainability and recycling, so are we as a company – in all our processes. That would lead you to think that less is more, right? Not always – in this case more is actually much more. From our great selection of faucets and accessories, we have taken a couple of items and put them together – upcycled them if you like.
The faucet
It has been more than 30 years since we started making our touchless faucets – and if you have read the previous blog posts about touchless faucets, you already know how they work. If not, here's a recap:
Our touchless faucets react to the movement of your hands – and are not dependent of the light in the room. This is all possible due to a patented PSD (Position Sensitive Detector) sensor, which allows you to use the faucet at any time of the day, no matter how dirty your hands might be.
The sensor sends a signal to the solenoid valve, which opens the faucet and the water starts flowing. And here's the best thing: when you are finished washing your hands and move them out of the sensor range, the water stops flowing. It won't run when you need to run.
Previous blog posts:
Level up: Taking the hygiene to the next level
The hand shower
The versatile Bidetta hand shower saw the light in the 60's. From the beginning, the handy hand shower was just meant to be an alternative to a bidet – but it turned out to be much more. The hand shower with a relative small size offers you a convenient way to:
· Take care of your personal hygiene after using the toilet
· Quickly wash your hair in the wash basin
· Fill up a flower vase or other tall containers
· Clean e.g. shoes in the wash basin without making a mess
This multi-purpose hand shower will make your everyday life easier – and lend you a helping hand when it comes to cleaning the bathroom.
A great combination
When combining the two function filled items, a touchless faucet and Bidetta hand shower, you get a truly great combination. You have the convenient touchless faucet that lets the water flow when you need it – and it'll make sure to close the water after you when you have to run. This makes the faucet not only water saving but also very hygienic as you don't have to touch it before washing or after washing your hands. At the same time, the sensor acts like a safety feature as it closes the faucets when it's no longer activated.
So, how does the Bidetta hand shower work in combination with touchless faucet? The function lies in the sensor – it's programmed to do different things depending on what you tell it to do – with your hand.
To activate the Bidetta hand shower you have to swiftly activate the sensor (max. 0.5 sec), then you push the trigger on the hand shower and the water is diverted to the hand shower. If you do not push the trigger the water will flow from the faucet. You can use the hand shower for up to 2 minutes before you have to re-activate the sensor. When you are finished using the hand shower you simply activate the sensor swiftly again (max. 0.5 sec) to let it know that you are done using the hand shower and the water will stop running.
To use just the faucet all you have to do is put your hands under the spout and the water starts flowing – it automatically closes when you no longer activate the sensor.
Oras Bidetta – 50 years of greatness
This year we celebrate the 50th anniversary of Oras Bidetta hand shower. Right from the beginning in 1968, Oras Bidetta made the visit to the bathroom easier and more comfortable. Let's take a trip...
Looking for a helping hand in the bathroom?
Want to have an easy fix in your bathroom for quickly washing your hair in the wash basin? Or to have easy access to water when you need to fill up tall containers? We have a solution for you!


text:
Why become a REALTOR®?
When you join, you become a member of three associations: Minneapolis Area REALTORS® (MAR), Minnesota REALTORS® (MNR) and the National Association of REALTORS® (NAR). All of these associations work together to bring you the tools and information you need to succeed in a constantly evolving industry.
Reliable technology and data 24/7, 365 days a year
Your membership provides you with access to one of the largest and best real estate databases in the country: NorthstarMLS. You can also access MAR's Affiliate Partner Directory, Infosparks and other tools to increase market visibility, improve productivity and enhance client communications.
Consumer trust and awareness. Guaranteed.
REALTORS® not only enjoy the opportunity to leverage the power of our advertising and marketing toolkit, they also distinguish themselves as market experts with access to ongoing market research that directly impacts you and your clients.
Courses to keep your license in good standing
Your investment offers programs and education opportunities to provide the courses necessary to keep member licenses in good standing. You'll find a wide range of professional development classes to meet your needs, including such topics as working with buyers, lead generation, negotiation techniques and more.
In good company
Whether you're at an educational meeting, a convention or a special event, MAR connects you with other real estate professionals and affiliated industry leaders at the local, state and national levels.
Strength in numbers from D.C. and beyond
Your REALTOR® investment supports a local, regional, national and international network, including a powerful government affairs program that has successfully defended your right to conduct business year after year.
Always in your corner
No problem is too big, and no question is too small. MAR's experienced staff is here to respond to your needs when you call, email or visit the office.
The office is open Monday – Friday, 8:00 a.m. – 4:30 p.m


text:
Germany saw a sharp 64% spike in the number of people seeking asylum in the country during 2013, taking it to a 14-year-high.
Just 14% of the more than 127,000 applications were approved, said Germany's interior ministry. Most of the applications came from Serbia, Russia, Syria, Macedonia, Afghanistan, Bosnia, Kosovo, Iran, Pakistan and Iraq. During the same year, net immigration to Germany hit a 20 year peak.
"Compared with other EU member states, Germany had by far the highest number of asylum-seekers in 2013," German Interior Minister Thomas de Maiziere said.
Tensions have been rising in Germany over the issue. A protest camp with around 200 asylum seekers was set up at the end of 2012 in Oranienplatz, a square in German capital Berlin.
They were demonstrating against the German system's inability to cope with the influx, leaving many asylum seekers unhoused and in bureaucratic limbo as shelters filled up.
"If I want to create a shelter for refugees, it takes a half year, a year, or more, just like with any construction project," Franz Allert, head of the Berlin city-state authority responsible for asylum seekers, told German newspaper Der Spiegel.
"It doesn't go faster ... just because they are asylum seeker shelters."
In November, thousands of protesters staged a pro-refugee rally in a German village in response to earlier action by the far-right National Democratic Party (NDP).
Around 2,000 people marched through Schneeberg in east Germany in a show of support for asylum seekers after right-wing extremists protested against a proposed reception centre for refugees in the village.
After Germany, France is the second most popular destination for asylum seekers heading to the EU.
In all the world, the US receives the most asylum applications, followed by Germany and then South Africa.
According to the United Nations, there are 15.4 million refugees across the world. Most of these – 80% – are in developing countries. Of all refugees, 46% are aged under 18.


text:
Standing ovations at the Matrix Theatre greeted the actors of Lucy Deutsch's Holocaust life story, No Time To Weep. The moving drama, told in song, and set in Hungary of 1944, tells the story of young Lucy, snatched from her home and shipped off to Auschwitz camp, where she is thrown apart from her parents and siblings. Having to survive only by her wits and the help of her fellow inmates, she comes out of the camps a changed young woman realizing that she can no longer play with her friends as she once had and more determined to succeed at the goals of her life and show Hitler that he could not win with her.
At first, the idea of having a Holocaust story told in song seemed a bit odd, but the acting and the words of the song overcame any reservations I might have held.
The lyrics, written by Lucy, herself, and Deedee O'Malley and the music composed by Deedee O'Malley and Ivor Pyres, and under the tutelage of the associate producer, Canter Estherleon Schwartz, herself a Holocaust child, fit the story perfectly that was directed by Ivor Pyres.
The heroine, young Lucy ages 14-28 (Caitlin Gallogly) was a fabulous singer and actress, but definitely assisted in her work by singer/actors Christopher Callen (Lucy 65), Sarah Ann Vail (Mary), Heidi James (Ruchy), Patricia Canale (Figia), Cat Hardy (Frida), Edward Gusts (Jacob), Vince LaSalvia (Mikey), Stephen Beitler (Shapsy), Jordan White (Olga), Daniella Cartun (German woman), Luke Edward (German officer), Lynde Houck (Shary), Garen Petrossian (Moshe), David Baer (German soldier), Flo Lawrence (Kapo), Hilary Prentice (Royja), Jennie Floyd (Sury), and Jerome St. Jerome (Shapsy's Father).
Costuming was done by Daniella Cartun while Derek Reymer did the music direction. Stage management was excellently done by Emi Avagdo while Kedar Lawrence did the lighting.
At the show, the company introduced a new mandelbroit (cookie) by Papa Ben's Kitchen. The proceeds from the sales of these sweets went to the Zachor Holocaust Foundation working for remembrance of the six million.
The theatre was honored by the presence of the real Lucy Deutsch, a prominent manufacturing artist in her own right, who has written several other books and scripts. Having been through the pain and suffering of Auschwitz, the future holds no surprises for her.
The story is heart wrenching, but well told. Despite it being about one of our darkest hours, it's also an inspiration for survival. On a scale of 10, I'd give it a 9.5. Bring your hankies!
On April 22, Yom Hashaot, the Day of Rememberance (for the six million) there will be a special ceremony and performance.
The play runs 8 pm Thurs through Sat and 2 pm on Sundays, April 14th - June 3rd. Tickets run $30 with discounts for seniors and students. (Promo code 007) Parking is always difficult around the theatre so allow time for that. Call 323 960 7780 or www.plays411.com/notime to reserve seats.


text:
Chapter 8
Nadia opened the front door when Leia rang the door bell. She were in her bathrobe. Leia laid her bag on the chair that stood in the hall. She asked her friend how she was doing and told her what was said in class. She gave her the notes so she could write them down later. Leia made some tea and they sat down by the kitchen table. Nadia put some biscuit on a small plate.
"So how's the hot teacher?" Nadia asked while taking a sip from her cup
"Please don't call him that"
"So it's by the first name already?" Nadia said with a smile
"He's hardly hot. Not anymore. More like a jerk" She said and drank some tea from her cup
"What did he do?"
"Please don't tell anybody"
"It's that juicy. Spill it out" Nadia said excited
"He kissed me"
"No way. I'm away for one day and this happens. So how was it?"
"You won't believe it"
"It was that good, huh? Did someone see?"
"I hope not. But here comes the jerk part" Leia continued and paused
"He tried to go further than that. And it was in the classroom"
"Oh no. He's a fast mover. I hope the door was closed"
"It wasn't"
"Now that's bad"
"I don't know why I gave him that impression. A kiss doesn't mean I want to sleep with him. Not yet anyway"
"You would expect that from high school boys but from a teacher at Uni. You would think a 43 year old man would have control over his feelings. But I guess you bring the teen in him"
"Wait, how did you know his age?" Leia asked surprised
"I asked from a classmate. Don't worry. A 20 year gap is kind of sexy"
"That's explains a lot. I was wondering how come he kissed like that"
"Well, he got the right target"
"We're getting off subject. We shouldn't praise him. He's a jerk" Leia said and poured herself another cup of tea
"First you drool over him and now he's a jerk. Things can't be that bad" Nadia said and took a bite from her biscuit
"He tried to have sex with me and then he wanted to give me a lift. I could have taken the bus"
"That's not a reason to call him a jerk. You know, he's just not teaching psychology. He could also teach you about life. It's not everyday you meet a man among all those 20- something aged boys"
"You really want us to be together, don't you? Well I can't. I'm his student and that's not right"
"It will be over in 3 months anyway"
"It's still wrong"
"Are you afraid you'll do something wrong? Something that will put him off?"
"No I'm just not ready"
"I think you are but you keep pushing it further and further. Does he know you're still a virgin?"
"So it's my virginity that's on the line now?" Leia said a little upset
"Isn't it? You keep talking about sex but you'll never do anything about it. When you finally meet someone, you don't take the opportunity"
"So I should sleep with the first guy I meet?"
"That's not what I meant. You just seem so excited about this one. I'm not saying you should sleep with him straight away. But you shouldn't give up"
"I am. Teacher/student relationships doesn't work. It just gets the teacher into trouble and I don't want that"
"If he takes the risk to kiss you in school with the door open, he doesn't care he does"
"You make it sound like it's OK. Go a head, have an affair with you teacher- kind of thing" She waved her hand in the air
"Now you're exaggerating. That's not what I meant at all. If you really like him, you shouldn't care he is"
"OK, next time we have a class, I'm gonna tell him that I want him in front of everybody. I'm really desperate" Leia sarcastly said
"Don't be like that. I know you wouldn't. It wouldn't be wise either"
"OK, I wouldn't even dare. That would be embarrassing" She said and smiled
"So what are you gonna do?"
"Nothing. He can do the hunting. He seems to love that. If he really wants me, he should do all the work"
"Make him suffer, right?"
"He already is. If he wants to play, I can play harder"
"I'm with you all the way" Nadia said and the girls smiled at each other


text:
Cashmere Baby Blanket
Cashmere Baby Blanket
These are beautiful, warm and cosy handmade 100% cashmere baby blankets. Made of soft and pure cashmere pashmina wool in Nepal by the experienced artisan. Every newly born baby needs warm and comfort right after the birth and hence this cashmere baby blanket is enough to meet both of these purposes. The baby blanket is light in weight and comes with silk satin border. Try this lovely cashmere baby blanket to keep your beautiful baby warm or to take it as a gift for baby showers.
When we become parents we naturally become more conscious while caring for our babies. We want to give them best no matter whether it is a toy, cloths or even a blanket.
Cashmere baby blanket is luxurious and a classic choice for babies because of the quality warm and cosy fabric. The cashmere (also known as pashmina) material is a comfortable for a newly born baby's sensitive skin and looks nice in the crib.
Choices in Design & Colour: Cashmere baby blanket is a popular choice while selecting the best baby blanket for babies. There are varieties of colours, sizes and designs for their baby.
Fabric Qualities: Fabric made of Pashmina is warm and comfortable to the wearer, and it has excellent draping qualities and soft texture. Pashmina is used widely for making shawls and scarves, sweaters, ponchos, fine coat, dress, and suit fabrics and for high-quality knitwear and hosiery.
Breathable material: The pure cashmere pashmina wool keeps body heat in during cold weather but allows the body to maintain a comfortable temperature in warmer weather without overheating.
Durable - Lasts for a long time: The handmade cashmere baby blanket should last for years as the child grows and can even be passed to siblings. A well-made pashmina blanket should not unravel or pill excessively though the cashmere products always need utmost care.
Soft & Delicate Texture: The cashmere often known as diamond fibre of Asia is popular for soft and delicate texture, is used to make baby blankets so it does not irritate the baby's sensitive skin.
We know that you have so many options when it comes to buy baby blankets. But when you begin to look for a store which offer 100% pure cashmere blanket with an affordable price tag your choice will be only limited to mimosa crafts. Our store is loaded with the finest collection of handmade cashmere blankets. All of our blankets are soft, water resistant and will keep your little one warm, cozy, and comfy as ever.
- Size (approx): 90cm X 90cm
- Weight (approx): 170gram
- We accept payment through PayPal and Direct Bank Deposit / Bank Transfer.
- Payments must be made within 3 days of purchase to secure your ordered products.
- All stock items will be shipped within the 1-2 business days and custom order (MADE TO ORDER) items will be shipped within 3 to 10 business days under normal condition after receipt of the payment.
- The buyer will be responsible for custom duty or any other applicable charge. Therefore, buyer is advised to check with his / her country's rules and regulation before purchasing the item. More...............
In an unlikely event if you are not satisfied with the purchased item for the reason other than change of mind,
- The returns will be accepted provided that the items are returned in its original condition within the mentioned time frame.
- The buyer will be responsible for return shipping cost. More...............
Note: Since most of our products are handmade,
- There may be a slight imperfection, irregularities or variation in shape & size and no two are alike.
- There might be a slight variation between displayed product picture and the real product because of the different timing of the photograph or different computer screen resolution. More.......................


text:
Making the Best of a Bad Purchase
I love Apricots and so does my 3-year-old son. Last summer he climbed up a ladder into an apricot tree and devoured 3 huge ones, never having tried one before. So in a fit of fear of missing the short apricot season entirely I purchased a case from a source I knew better than to trust in having good fruit. And I should have known better when, having asked the somewhat dumbfounded clerk if I could taste one before I purchased the case, I handed the other half to my son who took one bite and handed it back to me.
So I made two LARGE batches of jam, cursing my poor decision along the way. I typically add a bit of orange zest and juice to my apricot jam, something my grandmother always did (though she added pineapple as well) and with a bunch of lemon juice too, the jams are actually quite good. But now I understand why many people are uninspired by apricots. There must be a lot of bad apricots out there. Apricots that are mealy and flavorless or hard and flavorless not sweet and juicy and musky and heavenly like they can and should be.
One of my earliest childhood memories is of driving through the Columbia River Gorge to Hood River to pick apricots and climbing ladders in the hot wind of the Gorge in mid-summer and eating and eating them up in the trees. And then driving home dusty and sticky, the car filled with the sweet warm scent of apricots. They are really an easy fruit to work with too–a cinch to wash, no need to peel, and they're free-stone.
So a few lessons from this experience. 1) I've been lucky to have grown up with good apricots. 2) Good products need much less doctoring and are delicious as is so if you're after fresh eating, maybe better to skip them if they're not very good. 3) The practice of breeding fruit (or veggies) for portability and visual appeal rather than flavor is a shame. 4) I'll buy my apricots from the farmers' markets or u-pick in the future, even though I know that this jam will be welcome in the dead of winter.
So today I decided to turn the final bowl of sorry fruit into a cobbler. This is hands-down my favorite cobbler recipe. It was originally written for Italian Prunes (or plums as most now call them) but is equally good with apricots and peaches or a combination or with the addition of a few handfuls of blackberries.
It calls for a bit of cardamom and crunchy turbinado sugar on the tops of the biscuits and is a perfect combination of juicy fruit and light, creamy biscuits. And the poor apricots, doctored up with lemon juice and zest, and said cardamom cooked up into a very good cobbler.
Apricot, Peach, or Plum Cobbler
–Adapted from Claudia Fleming
For the Biscuits:
1 2/3 cups all-purpose flour (or half all-purpose and half whole wheat pastry flour)
3 tablespoons sugar
3 teaspoons baking powder
1/4 teaspoon salt
6 tablespoons butter, chilled, cut into 1/2 inch pieces
2/3 cup plus 1 tablespoon heavy cream
1 tablespoon turbinado sugar
For the Filling:
2 1/2 lbs of fruit (apricots, peaches, plums or a combination) to yield 6-7 cups
1/4 teaspoon cardamom
1/4 teaspoon cinnamon
1/4 cup sugar
Preheat oven to 375.
To make the biscuits, mix all dry ingredients in a large bowl. Cut the butter into the mixture with a pastry cutter until the butter is the size of large peas. Stir the cream in with a fork and gather the dough into a ball. Turn it out onto a floured work surface and shape the dough into 8, about 2-inch balls. Place on a baking sheet and flatten slightly. Refrigerate for 20 minutes or up to 2 hours. If you're in a hurry you can skip this step. I have had fine results as well.
Mix the fruit with the sugar and spices in a 2 quart gratin dish. I used cardamom and 3 teaspoons of lemon juice and the zest of half a lemon in my apricot version today and skipped the cinnamon. I also used a generous 1/4 cup of sugar. Taste the fruit before you bake the cobbler and adjust sugar to taste. Place the flattened balls of dough evenly on the fruit. Brush the remaining cream on the biscuits and sprinkle the turbinado sugar on top. Bake for 40-45 minutes until the fruit is bubbling and the top is lightly browned. Serve warm are at room temperature with whipped cream or vanilla ice cream.
And apricot cobbler for breakfast is a treat, even with second-rate fruit!
Mary Lane Stevens #
I remember eating Sarah's wonderful canned apricots and plums when we briefly lived with you after moving to Portland. (You, Katherine, were very small.) I remember thrifty Sarah pointing out that small apricots are not only cheaper, but you can fit more fruit into each canning jar.August 17, 2010
Mommy #
Very nice! Brings back memories for me too! And I want to try that cobbler so badly that I might just go out and look for a few last apricots. Benny is in need of more calories and I've been slacking on the food front.
MAugust 17, 2010
Gail #
You're not alone! I just had the same experience with peaches. I got a load of peaches from my CSA and they were out-of-this-world, but when I needed to supplement with a few extra for peach cobbler, I was woefully disappointed by the ones I encountered at my local market. They were totally lacking in flavor! So then I rode up the street to the fancy-pants gourmet market, and the peaches there were different in only one way: they were more expensive (but equally as boring — with my eyes closed, the one I tried could have been an underripe apple). Two bad batches of peaches later, I gave up and supplemented with blakcberries. Sticking with CSA and farmer's market fruit from here on out.August 18, 2010


text:
Opening in select cities November 7, The Theory of Everything centers on the inspiring and steadfast relationship between astrophysicist Stephen Hawking (Eddie Redmayne) and his wife Jane (Felicity Jones). The film, directed by Man on Wire filmmaker James Marsh, is based on Jane Hawking's memoir Travelling to Infinity: My Life With Stephen.
"This is a fascinating and formidable woman to be playing," said Jones. "It was a project where I knew that I would need to do a lot of research and a lot of preparation. When you're playing real people, you feel a sense of responsibility, because you know that they're going to see it at some people. It can sound a bit grandiose, but you want to do justice to their experiences – and Jane and Steven, they really lived extraordinary lives in an extraordinary way."
In the audio clip below, Felicity Jones talks about the prep work involved in tackling such real life women as Jane Hawking in The Theory of Everything and Nelly Ternan in The Invisible Woman.


text:
Four in Hand (Unabridged)
- $15.99
- $15.99
Publisher Description
She was unquestionably a lady. Still, that had never stopped him before. He could see that she was not, he thought, that young. Even better. Another twinge of pain from behind his eyes lent a harshness to his voice. "Who the devil are you?" In no way discomposed, she answered, "My name is Caroline Twinning. And if you really are the Duke of Twyford, then I'm very much afraid I'm your ward...."
Max Rotherbridge couldn't believe it. Along with the dukedom of Twyford, he - London's most notorious rogue - had inherited wardship of four devilishly attractive sisters! Including the irresistible Caroline Twinning. The eldest Twinning was everything he had ever wanted in a woman, but even Max couldn't seduce his own ward...or could he? After all, he did have a substantial reputation to protect. And what better challenge than the one woman capable of stealing his heart?


text:
Divorced. By Sue Lyon, 18, cine-nymphet (Lolitd) and teen tease (The Night of the Iguana): Hampton Fancher III, 26, sometime flamenco dancer, who was banned from the Iguana set for Lyonizing Sue; on grounds of mental cruelty; after ten months of marriage; in Santa Monica, Calif.
Divorced. By Dorothy Malone, 39, $3,000-a-week star of Peyton Place, TV's serialized sexpose of small-town life: Jacques Bergerac, 38, French lawyer-actor previously married to Ginger Rogers; on grounds of extreme cruelty; after five years of marriage, two children; in Los Angeles.
To continue reading: or Log-In


text: My colleague Mark Kerstetter is wrangling this weekend's Poetics gig at dVersePoets Pub, offering a prompt based on the art work of the Italian Surrealist Giorgio de Chirico. A little research into this artist and I found Le Vestali: La Statua Si Muove (The Vestal Virgins: The Statue Moves). The rest is a Hesch slant look at the art and reversal of roles.


text: Mr. Shaun McAfee, O.P. is the author of Reform Yourself! and other books, is the founder and editor of EpicPew.com, and contributes to many online Catholic resources. He holds a Masters in Dogmatic Theology from Holy Apostles College and Seminary. Shaun has made his temporary profession as a Lay Dominican and temporarily lives in Italy.


text:
Boogaloo Sam was inspired to create a new style of dance after watching some dancers who were locking on television. He created Popping, which is a dance that combines rigid robotic moves with loose flowing moves. Popping came about in the 60's and started with Boogaloo Sam in Fresno California. He taught his brother, Popin' Pete and later his cousin, Skeeter Rabbit how to be poppers. Boogaloo Sam created the dance group Electric Boogaloos which Poppin' Pete and Skeeter Rabbit were members of.
Boogaloo Sam (Sam Solomon)- Creator of Popping and Electric Boogaloos.
Popin' Pete (Timothy Solomon) – Boogaloo Sam's little brother. One of the orignators of Popping. Member of the Electric Boogaloos.
Skeeter Rabbit (Stephen NIchols) – Boogaloo Sam and Popin' Pete's Cousin. Another member of the Electric Boogaloos.
Mr. Wiggles (Steffan Clemente) – pioneer of hip-hop dance. Street dancer known for his popping skills. Member of the Electric Boogaloos.
Boogaloo Shrimp (Michael Chambers) – Street dancer known for popping, boogaloo and robot dancing. Also known for b-boying.
Salah Benlemqawanssa – hip hop dancer from France known for popping, animation and boogaloo.
Boogaloo – A style of dance where the dancer tries to give the impression that their body is lacking bones. The dance is loose, fluid and mimics cartoons or animated movies. The dance involves circular rolls of hips, knees, and head. Developed by Boogaloo Sam in 1975 and is the signature style of the Electric Boogaloos.
Dime Stopping – Abruptly coming to a stop after moving at a steady pace as if to "stop on a dime."
Popper – one who dances the popping style.
Botting (Robot)
Crazy Legs
Popping is typically danced to Funk and Disco music. In the 80's poppers would dance to electronic music or hiop hop music. Today we see poppers dance to a variety of genres of music including dubstep. Typically songs will be around 90-120 beats per minute and in 4/4 time signature.
Popping is often used in other styles of street dance in combination with other dance moves. The dance has been around for a long time and people are still dedicated to dancing in this style. The dance has changed slightly with new poppers dancing with the same moves to newer music. It seems as if this dance will never go out of style.
The roots are so strong and go back to the 60's and 70's. I think since the dance has been around this long, it isn't going to disappear anytime soon. With legends like Mr. Wiggles and Poppin' Pete this style of dance will never be forgotten. It has made it's mark in time. Dancers of all genres will continue to be inspired by popping and use it's fundamentals to incorporate into their dance moves.
3 comments
most of these moves, are styles actually….
Most of those "styles" are just exaggerated versions of the original popping pillars. Animation is a sub-style of popping.
The moves are styles but popping is the umbrella term…ppl with call them self's strutters or animators if that's what they do… But Sam didn't create popping only the eb style. Popping started in oakland then went south but different parts of cali developed different styles like pamona did waves