[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3564 [Tor Client]: Implement proposal 181 (optimistic data, client side)
#3564: Implement proposal 181 (optimistic data, client side)
-------------------------+--------------------------------------------------
Reporter: nickm | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Client | Version:
Keywords: | Parent: #1849
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by iang):
Replying to [comment:7 iang]:
> Replying to [comment:6 nickm]:
> > > You mean smaller than one stream window?
> >
> > I think so, maybe. Does that not seem reasonable to you?
>
> I guess the ideal number is "the amount of data you can send in one
RTT", unless you don't care if large uploads stall for a bit (but no worse
than they do today).
>
> What you're trading off is the probability the optimism is warranted
(the stream does open) against the wasted Tor bandwidth otherwise.
>
> So you can make a conservative choice, picking a limit that will handle
any reasonable HTTP GET request, for example, or HTTPS ClientHello, etc.,
but not large POSTs. ISTR that Google has a public data set of HTTP
request sizes. (Or maybe it's HTTP object sizes?)
It's indeed a histogram of the web page sizes (and related features), not
GET sizes: https://code.google.com/speed/articles/web-metrics.html
So not as useful for this particular purpose.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3564#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs