[ NNSquad ] Re: Traffic shaping law proposed in US

[Neil Davies <semanticphilosopher@googlemail.com>]

I think that you have to be careful here - you need to distinguish 
between identification and outcome - note NOT "per hop treatment".

Legislating how things are identified would be a big mistake, the vast 
majority of end-users are not sophisticated and rely on the (benign or 
even benevolent) ISP to work with them to deliver services (e.g. all 
traffic to port 5060 is "SIP). It must be non-discriminatory, yet 
feasible to deploy.

Outcome is what is important  - you want your stream of data, for a 
particular purpose, to be delivered with bounds on the loss and delay. 
Also you need to define (on a end-user basis) what happens when 
bandwidth resources are over used.

There is an underlying cost to delivering better quality (take a look at 
the underlying maths) - you need to structure the commercial offerings 
consistent with the underlying physics!

Neil Davies

Phil Karn wrote:
> Barry Gold wrote:
>
> > This sounds pretty good.  I would hope it would also permit a network 
> > operator to put limits on the _quantity_ of traffic to/from a given 
> > user.
>
> All this is fine, I think, as long as the operator doesn't 
> discriminate on the traffic it does handle. That is, the operator can 
> throttle users, charge them more for excess traffic, whatever, 
> provided that whatever traffic it *does* handle for a given user is 
> handled in a non-discriminatory way. It shouldn't look at the TCP 
> header at all, to say nothing of the data field. All routing decisions 
> MUST be based on the IP header and nothing else unless the user 
> specifies otherwise. (It's okay for port blocking, etc, to default on 
> as long as the user can ask to have it turned off.)
>
> Even with respect to the IP header, the operator can't discriminate 
> among destination addresses except as they relate to available 
> bandwidth. I.e., he can't explicitly block certain destination IP 
> addresses or give them lower priority, but he need not buy lots and 
> lots of upstream capacity to guarantee equal throughput to every 
> possible destination.
>
> If priority (non-FIFO) mechanisms are provided, they *must* be under 
> complete user control. That is, if the user wants his VoIP traffic to 
> get better treatment than his bit torrent traffic, he will have to say 
> so in the DSCP field of the IP header. (The meaning of the various 
> DSCP values will require standardization.)
>
> This doesn't stop the provider from penalizing a user's traffic, 
> including his VoIP traffic, if the user exceeds some sort of total 
> quota. It simply provides a way for the user to indicate to the 
> operator that, among his packets, some are more important than others.
>
> Again, I think a good analogy is to how the courts interpret the First 
> Amendment. It's okay for a town to require a permit for a parade or 
> public protest, but if they do they cannot discriminate on the nature 
> of that protest in any way (except, of course, that it has to be 
> peaceable). Any rules or fees must be exactly the same for everyone.
>
>
> > Appropriately includes (IMHO):
> > . Reducing the bit speed at the DOCSIS modem
> > . Dropping a portion(*) of the user's packets at any router under the 
> > ISP's control.
> > . "firing" the user (terminating the contract at the next renewal 
> > point or even immediately if allowed by ToS).
> > . Sending ICMP "Source Quench" packets.(+)
>
> ICMP Source Quench has been strongly deprecated, and I don't think 
> most stacks even respond to it.
>
> Dropping packets is a bad idea. It tends to decrease network 
> efficiency because of all the packets that consume resources only to 
> be dropped, and it could encourage gaming, e.g., tweaking TCP to be 
> much more aggressive with retransmissions.
>
> A much better way to implement this, I think, is to reduce the 
> priority of ALL of that user's packets. The operator should still 
> honor the relative priorities placed on those packets by the user, but 
> all of those priorities would be biased downward.
>
> > A really useful way to throttle down traffic, of course, is to make 
> > the "window" smaller (along with dropping some ACKs).  Unfortunately, 
> > this would involve modifying packets in a way that violates the 
> > end-to-end nature of TCP.  I really think SQuench would be best, 
> > except that a lot of stacks currently ignore it.
>
> Modifying TCP headers is totally out of the question.
>
> > Maybe we need a new RFC: an ICMP query that asks "do you respond to 
> > source quench", with the response giving a level of handling (I'm not 
> > sure what the levels would mean, but at the very least 0: I ignore 
> > them, 1: I send fewer and smaller packets, 2: I retransmit less 
> > often, 3: 1+2.)
> >
> > If the host answers "0" or doesn't respond, the intermediary should 
> > be allowed (explicitly, by RFC) to modify the window field in TCP 
> > headers, in order to ensure that traffic does not exceed their 
> > ability to handle it.
>
> I don't think this is necessary. All you have to do is to drop that 
> user's priority relative to the other users. If some operators want to 
> reduce the bit rate of the user's modem, that's their choice but I 
> don't think it's as good as changing the priorities.
>
> I still think that priority queuing is the silver bullet here. Used 
> effectively, it could satisfy both the operators and the users.
>
> --Phil