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

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

Thanks Roland. My main point is that I do believe that we have an
interesting problem at hand, one that goes beyond bashing Delta Hotels
(however fun it can be :-) ).

Funny fact: some of the most interesting IETF-related discussions that
I've had have been on the lists *after* the event itself :-)

cheers!

Carlos

On 8/4/11 5:35 PM, Roland Bless wrote:
> Hi Carlos,
>
> On 04.08.2011 17:50, 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
> QoS is there for differentiation of packet/flow treatment,
> i.e., managed unfairness, while congestion management tries
> to provide fairness between users/flows in a best-effort class.
> QoS still doesn't solve the problem of trying to share the capacity
> between users in the same QoS class.
>
>> 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
> Yes, indeed, DDoS flooding, misbehaving flows and unbalanced traffic
> matrices may still cause problems for overprovisioned networks.
>
>> 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.
> Yes, but this is also true for more clever congestion management schemes.
>
>> 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.
> There are signaling solutions out there for this, e.g., NSIS
> http://tools.ietf.org/wg/nsis/ provided solutions for both
> Port management for NAT/Firewalls as well as for QoS signaling.
> Giving a tool into the users' hand so that they can actually
> decide what is more important and should be treated with better
> QoS would be a good thing also from the perspective of net neutrality.
> But the complexity of providing everything (control plane + DiffServ
> etc.) for QoS support is obviously still a too high effort.
>
> Regards,
>  Roland

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