Traffic class QoS patch wanted?

[Geoffrey Goodell]

Mike,

In essence, your proposal is functionally equivalent to IP
Differentiated Services (DiffServ), RFC 2474.

As with DiffServ, your proposal has several shortcomings regarding what
you describe as "cheating."  It is always in the best interests of an
individual client to cheat if it can, and your method for preventing
cheating (i.e., checking the port number) will yield both false
positives and false negatives.

The argument that "this is a good practical measure for now" is tenuous,
since there are inevitable side effects that cannot be overlooked.  By
encouraging cheating, the QoS bit will encouarge the use of random or
misleading port numbers in order to fool the port-number-based sanity
check.  Like other protocols that use port number as a meaningful way of
differentiating services, this proposal if implmented will encourage the
overloading of specific port numbers for different kinds of purposes,
rendering them generally useless.  There is a reason why more and more
services on the Internet listen on port 80...

Next, consider this port-number issue in a greater context: one can
think of port numbers as a form of "transport-layer routing," which is
to say that when a host receives an IP packet, it determines
(demultiplexes) to what process to send that packet based upon its port
number.  Remember that Tor is ultimately about decoupling identity from
routing information; making a gratuitous exception for what is
ultimately just routing at the transport layer seems inappropriate and
even dangerous.

Geoff

On Tue, Feb 15, 2005 at 03:46:25AM -0600, Mike Perry wrote:
> Thus spake Mike Perry (mikepery at fscked.org):
> 
> > > Sure, we accept patches, and do so often.  One issue is that we get
> > > way more design ideas than we get patches, so we don't always assume
> > > that people are going to work on their designs.  If you want to get a
> > > significant design feature into the main tor distribution, it's
> > > usually a good idea to submit a patch to tor-spec.txt first, so we can
> > > talk about the actual details of the design before you spend too much
> > > time on the implementation.
> > 
> > Ok. I'll see about doing this next.
> 
> Attached. Let me know what you think. The one thing I'm not sure about
> is how an OR might determine the version of an OP that connects to it
> to satisfy the last paragraph. I'm assuming all OR to OR connections
> can check the directory platform string for version info.. But what of
> OP to OR?
> 
> -- 
> Mike Perry
> Mad Computer Scientist
> fscked.org evil labs

> --- tor-spec.txt	2005-02-15 01:38:23.878301675 -0800
> +++ tor-spec.txt.MP	2005-02-15 01:40:28.452287305 -0800
> @@ -112,13 +112,35 @@
>     fields:
>  
>          CircID                                [2 bytes]
> -        Command                               [1 byte]
> +        Priority                              [2 bits] (high bits)
> +        Command                               [6 bits] (low bits)
>          Payload (padded with 0 bytes)         [509 bytes]
>                                           [Total size: 512 bytes]
>  
>     The CircID field determines which circuit, if any, the cell is
>     associated with.
>  
> +   [v0.1.0-Proposed] The Priority field is used to provide a form of QoS
> +   on the network. Packets are marked with this field according to their
> +   desired latency:
> +         0 -- Unbuffered interactive traffic (ssh, telnet, rdesktop, tcp dns)
> +         1 -- Application buffered interactive traffic (web, irc, aim)
> +         2 -- Data transfer (ftp)
> +         3 -- Bulk Traffic (bit torrent and the rest)
> +
> +   For the time being, this priority field is used only with RELAY cells, and
> +   all the other commands will have an implicit 0 priority. When RELAY cells
> +   arrive, low value cells SHOULD be forwarded to the next OR before
> +   higher value ones.
> +   
> +   To avoid 'cheating', exit servers SHOULD verify that the priority fields do 
> +   in fact match the destination port.
> +
> +   These bits MUST be masked off when forwarded to ORs whose platform string
> +   in the directory is below v0.1.0. To discourage the use of old clients 
> +   to boost bulk traffic priority, this field MUST be set to 3 upon receiving 
> +   cells from an OR or OP whose version is below 0.1.0.
> +
>     The 'Command' field holds one of the following values:
>           0 -- PADDING     (Padding)                 (See Sec 6.2)
>           1 -- CREATE      (Create a circuit)        (See Sec 4)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20050215/fd3a87e1/attachment-0001.pgp>