last mile prioritization (was Re: Enterprise VoIP Peering Point? )

[Chip Sharp <chsharp@cisco.com>]

At 12:56 PM 8/11/2004, Mark R. Lindsey wrote:
> I've heard this a few times in the past few weeks:
>      "Sorry, my vonage phone is breaking up. Can you repeat that?"
>
> Many of the folks that I talk to who are using un-prioritized bandwidth 
> into their homes/small businesses frequently have problems. These are DSL 
> and Cable users.
>
> The cheap end-user equipment could easily have ready support for voice 
> prioritization. E.g., the D-link DVG-1120 specs say that "Voice service is 
> prioritized over the data traffic"
> (http://www.dlink.com/products/resource.asp?pid=169&rid=652)

Yep.  CPE *could* prioritize the VoIP on the uplink *if* it was configured 
correctly to do so.  A number of folks I know do this at their home 
offices, but they tend to be engineers that helped build the stuff (& 
running IOS(TM)).  The CPE could also mark the DSCP bits for higher 
priority, but it is likely that the SP would remark the DSCP bits at the 
network edge unless this was negotiated previously.

> DSL and Cable IP providers could do something similarly simplistic that 
> would go a long way on the bottleneck links; e.g., prioritize UDP higher 
> than TCP.

What is the business plan for the access provider to do this?  Where is the 
incremental revenue?  How much would you pay them for this service?

This would probably require a little more granularity.  Prioritizing all 
UDP over TCP sounds like a potential attack vector.

> "Headroom" on high-capacity links is *probably* primarily because the 
> typical bottleneck link sizes between users and their servers is so small. 
> Most of my downloads from popular servers max out <400kbps, even though I 
> have a lightly-loaded 18Mbps link into my office that's barely used. 
> Something out there is traffic-shaping the download, or else my flow 
> crosses a congested link. In the latter case, unprotected real-time flows 
> across that congested link will have problems.

Is this using TCP?  If so, it could be a number of other reasons.  For 
example, the window might be too small for the bandwidth*delay product.
Also, I've found that a lot of my TCP flows never approach the bandwidth of 
my downlink because they don't last long enough for TCP to ramp up (e.g., 
due to slow start) to the max window.  Or it could be just what you mention 
above.


> ---
> Mark R. Lindsey     Engineers' Consulting Group
> Office: 229-244-2099x2207; Mobile: 229-630-5553
...snip... 


--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.