🚀 go-pugleaf

[POSTED TO comp.dcom.modems.cable; PLEASE REPLY THERE]

In <3A7C64FD.D78860D4@mynetwatchman.com>, Lawrence Baldwin
<baldwinlSPAMMENOT@mynetwatchman.com> wrote:

>John Navas wrote:
>> 
>> Again, this is only a concern on *asymmetric* links.  Saturation of the
>> uplink on a *symmetric* path will not have an adverse effect on the
>> downlink.
>
>Huh? Why not?
>
>All our differences (not that we NEED to agree) seem to hinge on this
>point, so I'll focus here for now.
>
>Assume I've got my own dedicated, 10Mbps, full-duplex link.  If I
>saturate the
>upstream with 10Mbps of one-way UDP traffic (a video stream let's say),
>my downstream
>throughput potential (for a TCP session) would be severely limited, no?
>
>The returning ACKs are going to be impeded whether the bandwidth
>potential on the link is assymetrical or not.
>
>All that matters is whether the upstream is saturated or not??

These are two different scenarios: threshold effect versus graceful
degradation.

What makes the *asymmetric* case special is that saturation of the
slower direction effectively turns the asymmetric link instantly into a
symmetric link at the slower speed; e.g., 1500/128 becomes 128/128,
thereby wasting about 90% of the downlink.

When the pipe is *symmetric*, it is of course possible to saturate one
direction and thereby affect utilization of the other direction, but the
effect is considerably different (and often controlled with traffic
shaping).

A single UDP stream of 10 Mbps is pretty extreme, and in any event we're
generally talking DS3 or better in this context (45 Mbps and up)
handling a great many simultaneous streams.  Even without traffic
shaping, these streams compete for capacity on a per packet basis, and
the overall load tend to degrade relatively gracefully; e.g., if demand
exceeds capacity by 10%, then the degradation in the other direction
would typically be no more than that (and probably less), rather than
the 80-90% degradation that can suddenly occur on an asymmetric pipe at
the point of saturation.

>Oh, and BTW, EVERY single loop I've analyzed is capable of 256Kpbs,
>REGARDLESS of
>loop length.

Thanks for the confirmation -- that's what I expected.

>> I've not seen any real evidence of a significant problem in this area --
>> have you?  

>My DSL get's slow too...impossible to know why without having backbone
>access.

A typical symptom is a jump in latency on traceroutes going through the
congestion point.

>BTW: I'm NOT frustrated by this conversation...as always I appreciate
>the engaging dialog.

Me too -- I've enjoyed the discussion, and learned quite a bit in the
process, as well as gained some new perspectives.

-- 
Best regards,
John Navas     <http://navasgrp.home.att.net/>
     CABLE MODEM/DSL GUIDE:  <http://Cable-DSL.home.att.net/>