Internet downstream QoS

Due, I suspect, largely to my imprecise language in my original post, I got mixed feedback. I'll try to rephrase and hopefully clear things up.

Goal: Ensure bulk traffic cannot consume more than 4% of my downstream link during times of congestion. If not congested, can consume as much of the link as they want. For the sake of example, let's say "bulk traffic" is streaming video, e.g. YouTube.

Siutation: * Cisco ISR * DS3 circuit - WAN interface: Serial0/0/0 * LAN interface: GigabitEthernet0/0

What I understand so far:

1. The ISR receives packets from its WAN interface serially (one at a time), and therefore, I have zero control over queueing (the order in which downstream packets arrive at the ISR).
2. I is officially The Wrong Idea(R) to perform any traffic shaping on the WAN ingress interface (Se0/0/0).
   1. All shaping (regardless of interface) should always be done on interface egress, due to egress queues having much more hardware resources available.

What I think is possible:

1. Even though I have zero control over the order in which my WAN interface receives packets, I can choose to drop or queue packets as they egress my ISR, via its LAN interface.
2. Selectively dropping TCP packets will invoke its slow start algorithm: "If a loss event occurs, TCP assumes that it is due to network congestion and takes steps to reduce the offered load on the network. These measurements depend on the exact TCP congestion avoidance algorithm used."
3. Invoking slow start at the ISR's LAN egress interface will cause the TCP flow(s) to back off their congestion window, until they no longer experience loss.
4. This will indirectly reduce the bandwidth load on WAN ingress for these TCP sessions.
5. This necessarily frees up WAN ingress bandwidth for other traffic.
6. Therefore, it is possible to achieve stated goal above, by applying shaping to those classes of traffic, on the ISR's LAN egress interface (Gi0/0).

If all of the above holds true, here's how I might implement it with minimal config overhead:

1. Create class-maps which match both DSCP values and their associated access-lists to classify traffic
2. Create a WAN policy-map which both sets DSCP values and applies shaping (CBWFQ and WRED) according to my QoS strategy
3. Apply this policy-map to WAN egress (Se0/0/0)
4. Nest this policy-map inside another for LAN egress, which shapes bandwidth to match WAN bandwidth. This is necessary to artificially induce congestion, since the LAN egress interface is 1Gbps whereas my WAN is only 45Mbps.
5. Apply the second policy-map to LAN egress.

My approach:

• Assume the referenced access-groups are correctly marking traffic for each class.
• Assume I'm also conforming to QoS best practices by doing ingress marking for each class of traffic at the user-facing LAN edge.
• Yes, I know this results in marking WAN egress traffic with DSCP values that my upstream ISP won't honor. I don't think that matters.

Example config:

! class-map match-any VOICE match dscp ef class-map match-any INTERACTIVE-VIDEO match dscp af41 af31 class-map match-any NETWORK-CONTROL match access-group name NETWORK-CONTROL match dscp cs6 class-map match-any SIGNALING match dscp cs3 class-map match-any TRANSACTIONAL-DATA match access-group name TRANSACTIONAL-DATA match dscp af21 class-map match-any BULK-DATA match access-group name BULK-DATA match dscp af11 class-map match-any SCAVENGER match access-group name SCAVENGER match dscp cs1 ! ! policy-map WAN-EDGE class VOICE set dscp ef priority percent 10 class INTERACTIVE-VIDEO set dscp af41 priority percent 23 class NETWORK-CONTROL set dscp cs6 bandwidth percent 2 class SIGNALING set dscp cs3 bandwidth percent 2 class TRANSACTIONAL-DATA set dscp af21 bandwidth percent 33 fair-queue random-detect dscp-based random-detect dscp af23 40 64 random-detect dscp af22 45 64 random-detect dscp af21 50 64 class BULK-DATA set dscp af11 bandwidth percent 4 fair-queue random-detect dscp-based random-detect dscp af13 40 64 random-detect dscp af12 45 64 random-detect dscp af11 50 64 class SCAVENGER set dscp cs1 bandwidth percent 1 class class-default bandwidth percent 25 fair-queue random-detect dscp-based random-detect dscp 0 50 64 ! interface s0/0/0 service-policy output WAN-EDGE policy-map LAN-EDGE class class-default shape average 44736000 service-policy WAN-EDGE ! interface g0/0 service-policy output LAN-EDGE 

Will this config achieve the stated goal of ensuring certain traffic (say BULK-DATA) cannot exceed approximately 4% of downstream bandwidth?

If not, why not? And what is the correct way to manage donwstream bandwidth when you don't control the upstream nodes?