[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #13978 [Ponies]: Get tor working with ns-3
#13978: Get tor working with ns-3
-----------------------+-------------------------------------
Reporter: teor | Owner:
Type: task | Status: new
Priority: normal | Milestone: Tor: very long term
Component: Ponies | Version: Tor: unspecified
Keywords: tor lorax | Actual Points:
Parent ID: | Points:
-----------------------+-------------------------------------
We could use ns-3's direct code environment (DCE) or perhaps their sim
kernel to run tor.
{{{
[14:29] <Yawning> (you know what would be a neat gsoc project? figuring
out how to get Tor to play nice with ns-3)
[14:31] <Yawning> (yes, we have shadow, but ns-2/ns-3 is the standard for
certain kinds of research)
[14:33] <teor> Yawning: re ns-3, that would be porting tor to the Direct
Code Execution environment?
[14:34] <Yawning> teor: yah, or looking at it
[14:34] <Yawning> ideally running a full test network
[14:34] <teor> Do we know how large the gap is?
[14:35] <Yawning> no idea
[14:35] <Yawning> last time I was doing this sort fo work, it was called
ns-2
[14:35] <Yawning> :P
[14:38] <Yawning> teor: I was really suprised that they wrote shadow
instead of extendign ns, but I never asked why they did that
[14:38] <teor> they?
[14:39] <Yawning> them tor folks
[14:39] <Yawning> :P
[14:39] <teor> It looks like we'd have to avoid clock_gettime in ns, and
might have to be really careful around threads and processes
[14:40] <Yawning> yah, it's not something I'd expect to be easy
[14:40] <teor> According to
http://www.nsnam.org/docs/dce/release/1.0/manual/html/dce-user-tech.html
#api-coverage
[14:40] <Yawning> but it'd be really strong for stuff likelooking at kist
[14:41] <teor> And we might be missing some important APIs
[14:41] <teor> s/we/DCE/
[14:42] <Yawning> hey, that's why I said it was a gsoc project :P
[14:42] <Yawning> for a really really enthusiastic student
[14:42] <dgoulet> hrm ns-3 is an offline simulator and by that I mean it
does not use the OS network stack for experiment, not sure if that would
reflect correctly reality
[14:43] <teor> The kernel can be used, see
http://www.nsnam.org/docs/dce/release/1.0/manual/html/dce-kernel.html
[14:43] <teor> Well, kernel sources
[14:44] <Yawning> teor: that's new-ish
[14:44] <Yawning> but yeah
[14:44] <dgoulet> ouf work++ to make it work with the kernel eheh
[14:45] <Yawning> dgoulet:all the researchers do their modeling with ns
and then write the kernel patches :P
[14:45] <dgoulet> reserach and kernel patch in the same sentence! wow :P
:P
[14:46] <Yawning> yah well the tcp research community is filled with
interesting people >.>
[14:46] <dgoulet> Yawning: I guess if you want to implement some new nice
TCP congestion algorithm in kernel, that makes sense but testing userspace
app on top of that, does that work well?
[14:46] <teor> Well, I know what I need to do next, and it's not this :-)
[14:46] <Yawning> for something like what we want to do in certain cases?
[14:47] <Yawning> I'd want a lot of the tooling or something similar >.>
[14:47] <Yawning> but yeah, ENOTIME
[14:47] <Yawning> and maybe shadow does all of what I want
[14:47] <dgoulet> right for sure a nice big network simulation would be
awesome
[14:48] <teor> Yawning: ENOMEM as well, sometimes
[14:48] <Yawning> if for say we wanted to move to sctp or a udp transport,
we'd need simulation capabilities like this
[14:48] <dgoulet> indeed
[14:49] <Yawning> (and it's the sort of tool that people that cound do
"how to make tor faster" would be faimilar with)
[14:49] <Yawning> just an idle thought, if I find a younger version of
myself with more time on their hands than I have, I'll suggest it to them
:P
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13978>
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