[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Idea: Using the SPDY protocol to improve Tor performance
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: Idea: Using the SPDY protocol to improve Tor performance
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Fri, 5 Feb 2010 11:03:58 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Fri, 05 Feb 2010 11:04:13 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hgxaYhsc7TQuVQP/p52Q6qhFENX1P+kQDsRqaVQWG/g=; b=EQTRBeIEbRXHgJdKgJo/MKCt82Uyu4lfkugrpbATVyzvCIbrpcAyb/q/c5ZJ7tJVUR 8NNy4gKZcvJvpFBpUIoEtSrtPH7XFKMubedZFHXG+njkVFz/52F86XolM/8WICZ+XNO+ VAY+CbjrLnenpGzFyc95RnBuTsFZi7yPXs96A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=q9a5YGcuRllLAS4GCjw1uEwSf5i3RW0jC8KuzRaR0Z0aR93GPUVmsEDJjIviwHnqqH HVYEtqncfTbI9g+JNPpL3PNWKhSODDLuGyNMbGy85RrsYtp3IIge0KZSUQfegYLV1oRd NG5pb1QnkFge3RvZe+599rl1z91mzYI8K6ABY=
- In-reply-to: <20100203220002.GF30954@xxxxxxxxxxxx>
- References: <20100203220002.GF30954@xxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
> 3. Design outline
>
> One way to implement the SPDY proxy is for Tor exit nodes to
> advertise this capability in their descriptor. The OP would
> then preferentially select these nodes when routing streams
> destined for port 80.
>
> Then, rather than sending the usual RELAY_BEGIN cell, the OP
> would send a RELAY_SPDY_BEGIN cell, to indicate that the exit
> node should translate between SPDY and HTTP. The rest of the
> connection process would operate as usual.
>
> There would need to be some way of elegantly handling non-HTTP
> traffic which goes over port 80.
I think there's a more generic mechanism lurking in the wings here.
SPDY is only one of several possible exit-side optimizing techniques
that might exist, and it seems overkill to add a new relay cell type
for each one we want to play with. I'd suggest that instead, the
begin cell should tell the exit what kind of traffic transformation it
ought to perform, if any. This could either be a new field in the
standard begin cell format, or it could be a new
RELAY_BEGIN_somethingorother cell type.
(As Scott mentioned in another thread, it is indeed a pretty basic
requirement that exits should not modify the streams they relay
without being asked. However, there's nothing that says we can't add
a facility for asking them.)
Of course, if we aren't careful, this could partition clients. We
need to make sure that any transformations we support on a
non-experimental basis are going to be used by a pretty large
proportion of the userbase, or else users will risk standing out.
On performance: experiment seems like our best bet for seeing whether
and to what extent this actually helps in practice.
--
Nick