[ NNSquad ] Re: Traffic shaping law proposed in US

[Barry Gold <bgold@matrix-consultants.com>]

Phil Karn wrote:
> I would hope that any such law would permit:
>
> voluntary traffic shaping done by or with the explicit consent of the end user,
> and in his interest (e.g., ensuring that his VoIP gets through when he's running
> Bit Torrent);
>
> creation of customer-controlled priority schemes, again designed to ensure that
> real-time traffic is handled expeditiously;
>
> carriers are banned from any and all discrimination on the basis of traffic
> content, including port numbers. Any port blocking must be under the control of
> the user.
>
> The basic theme here, of course, is control by the end-user and not the network
> operator.

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.  If the network is set up to allow a user to consume (say) 20 GB 
of download and 5GB of upload traffic per month, the operator should be 
allowed to react appropriately -- even though short-term burst speeds 
might be much higher, say 3MB/sec and 1.5MB/sec.

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.(+)

(*) determined based on quantity, _not_ service used.
(+) It is my devout hope that future protocol stacks will do something 
useful with these; it really is the best "neutral" way for a network 
operator to manage the quantity of traffic.

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.

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.