[ NNSquad ] Re: Traffic shaping law proposed in US

[Phil Karn <karn@ka9q.net>]

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