Re: [81attendees] sucky Delta hotel network (and bufferbloat)

["Carlos M. Martinez" <[e-mail]>]

For the record, I wasn't trying to argue with Randy :-)))

I just wanted to state my opinion on what I believe is a real problem we
might have to work on.

On 8/4/11 1:05 PM, Jim Gettys wrote:
> On 08/04/2011 11:50 AM, Carlos M. Martinez wrote:
>> I fail to see a better argument for implementing QoS than what happened
>> to the Delta Hotel in QC. I agree that QoS has been somewhat bastardized
>> by network operators and used only for extracting a premium for things
>> that should work anyway.
>>
>> Arguing that every network should always be overprovisioned encourages
>> wasteful behaviour on all parts and puts many players in an impossible
>> position. It might be not so impossible in the US/Canada (although even
>> there Delta Hotels showed us that it can also happen), but it's
>> definitely the case in other regions where BW costs are still quite high.
>>
>> Pretending that congestion does not exist will not make it disappear,
>> and arguing that the cure for congestion is overprovisioning creates a
>> situation where networks will always experience periods of poor
>> perceived quality, as congestion and provisioning happen on different
>> time scales.
> I don't think that was what Randy was saying though....
>
> I believe he was agreeing with my comment that while QOS is useful, it
> won't solve the bufferbloat problem.  QOS just moves who suffers most,
> and having buffers perennially full makes them malfunction in
> general.  It's why if I have to choose between QOS and working AQM,
> I'll pick working AQM all the time.
>
> Modern operating systems hardware and applications will congest any
> edge link; congestion in the edge (and a hotel is clearly the edge) is
> going to be with us forever.  Handling congestion properly in this
> environment is now absolutely essential.
>
> Basically, over CONUS delays, a single TCP connection on WinXP won't
> do over 6 MBps (no TCP window scaling).
> Later versions of Windows rate limit to below that of a 100Mbps
> ethernet switch (saturating most wireless and broadband links).
> Everything else will saturate to gigabit or more without blinking twice.
>
> Saturation of the edge is the *normal* situation; we just didn't
> notice when BitTorrent  saturated links using many TCP connections on
> XP years ago, so we lost years recognising what was happening.
>
> To solve congestion requires *timely* notification of the end points
> to slow down rather than tail drop off grossly bloated buffers, and
> right now, we only have packet loss to do that signalling.  It's
> often/usually so bad that TCP congestion avoidance is no longer
> functioning. Getting ECN enabled would give us congestion signalling
> without necessarily having packet loss.
>
>
>> Granted there can be "good" players who always invest ahead of the
>> curve, but, let's be honest here, they are the minority.
>>
>> Dropping packets is a bad thing. However, dropping packets blindly (as
>> in pretending congestion does not exist) is much worse. The network
>> should avoid dropping packets at all costs, but if it has to drop, then
>> it should do it smartly and avoid making the situation worse.
>>
>> I do believe there is a management problem in the same sense as there is
>> with CGNs and port forwarding, which has lead to the creation of PCP. It
>> is basically a remote management protocol allowing customer-provider
>> interaction (ATM UNI anyone ??? :-)))) ). Well, maybe we could do
>> something for QoS. Phoning your ISP each time you need to forward a port
>> is every bit as impracticable as phoning the ISP to create a QoS queue.
>>
>> Warm regards,
>>
>> Carlos
>>
>> On 8/4/11 12:30 PM, Curtis Villamizar wrote:
>>> Dave,
>>>
>>> I didn't want to jump on this but I agree with your point.
>>>
>>> QoS in providers today is used to prioritize packets for people paying a lot more than others for such things as VPN services.  The rest get usually extremely good "best effort" service as has been the case for most providers who have survived over the last decade or two (survived in some form or another, generous buyouts in the mid to late 1990s not withstanding).
>>>
>>> There can be improvement.  Good to hear that there is interest again.  The bufferbloat discussion and work and the mention of transport area activity is a symptom of interest and activity regarding doing things better in the host, CPE, and access/edge devices.
>>>
>>> Curtis
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:81attendees-
>>>> [e-mail]] On Behalf Of Dave CROCKER
>>>> Sent: Thursday, August 04, 2011 6:25 AM
>>>> To: [e-mail]
>>>> Subject: Re: [81attendees] sucky Delta hotel network (and bufferbloat)
>>>>
>>>>
>>>>
>>>> On 8/3/2011 5:46 PM, Randy Bush wrote:
>>>>> qos is about whose/which packets to drop.  i am not paid to drop
>>>>> packets, i am paid to deliver them.
>>>> Excellent.
>>>>
>>>> Let's ignore capacity limits and congestion completely.  The knee of
>>>> the curve
>>>> is a waste of our efforts.
>>>>
>>>> Think of how much simpler life would be if we paid no attention to
>>>> downsides.
>>>>
>>>> Armies would never give thought to retreat.  Armies are there to
>>>> advance, not
>>>> retreat.
>>>>
>>>> Carry this further and they would not have to worry about soldiers
>>>> getting
>>>> injured.  Armies are for hurting the other guys, not getting hurt.
>>>>
>>>> The medical profession would never have to worry about patients dieing.
>>>>
>>>> Investors would never have to worry about the market going down.
>>>>
>>>> Wouldn't it be great if a clever sound bit really did eliminate the
>>>> need to
>>>> worry about unpleasant realities?
>>>>
>>>> d/
>>>>
>>>> --
>>>>
>>>>    Dave Crocker
>>>>    Brandenburg InternetWorking
>>>>    bbiw.net
>>>> _______________________________________________
>>>> 81attendees mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/81attendees
>>> _______________________________________________
>>> 81attendees mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/81attendees
>>
>>
>> _______________________________________________
>> 81attendees mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/81attendees
>

-- 
Carlos M. Martinez
LACNIC I+D
PGP KeyID 0xD51507A2
Phone: [phone] ext. 4419