Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stoatwblr]

I've been reading a few of papers on technbiques used to detect and combat PtP traffic (I don't mind being throttled but I do mind it being "too much" or a total block.)

It seems that now that most traffic is encrypted by default on most networks, detection will move towards picking up known timer intervals.

One way of combatting this is to provide some degree of randomisation and jitter in those timers, the question is how much it can vary in a cyclical basis. (for various reasons I tend to use prime numbers for timers (and their offset ranges) whenever possible as it scatters things around more evenly and avoids timer convergance problems)

Is changing the network timers possible on amule/emule without breaking other clients? Is it desirable?

ie: How tightly must the clients adhere to heartbeat timers, or are the current values simply a matter of convention?


http://pam2009.kaist.ac.kr/paper/54480155.pdf (see page 3 and 4)

http://www.di.ubi.pt/~mario/files/MScDissertation-DavidCarvalho.pdf is a few years old but worthwhile reading.

Comments?
 
What got my attention is this comment in the Kaist paper:

"The third pattern of periodic group communication behavior is a direct consequence of how BitTorrent-like protocols might implement the tit-for-tat mechanism. As described in [5,10], each peer uses two timers (10 seconds and 30 seconds) to decide whether to choke and optimistically unchoke neighboring peers, respectively. This results in the synchronization of Start Events (SE) and End Events (EE) at the beginning of the time intervals, as illustrated in Figure 1(c)."


Another advantage of using variable timers is to prevent the possibility of the entire network inadvertently falling into "lock step" and generating damagingly large network pulses, due to external influences such as shaping attempts.

(this is a simlar effect to what happens when soldiers march across bridges and why they must break step (walk randomly) when crossing them. For another example, the London Millenium "wobbly bridge" oscillated at close to normal walking speed, which caused people to fall into that rhythm and it was the feedback cycle from this which caused it to "wobble". I've observed clustrers of computers fall into a network-wide "heartbeat" in LAN environments and this in turn has caused trouble with fileservers)

[Stu Redman]

It seems that now that most traffic is encrypted by default on most networks, detection will move towards picking up known timer intervals.

Citation needed. 

"The third pattern of periodic group communication behavior is a direct consequence of how BitTorrent-like protocols might implement the tit-for-tat mechanism. As described in [5,10], each peer uses two timers (10 seconds and 30 seconds) to decide whether to choke and optimistically unchoke neighboring peers, respectively. This results in the synchronization of Start Events (SE) and End Events (EE) at the beginning of the time intervals, as illustrated in Figure 1(c)."

I don't think we have anything like that in our code. We don't have tit-for-tat to start with, at least not in the sense it's described here.

[stoatwblr]

It seems that now that most traffic is encrypted by default on most networks, detection will move towards picking up known timer intervals.

Citation needed. 

Some of the suppliers trying to sell me kit at $orkplace are talking about "multifaceted" ways of detecting/blocking PtP traffic and claiming particularly that they can target edonkey and BT networks, even when emule is running in Kad-only mode.

They won't elaborate on "how" but they'd already said they don't try to crack into the obfuscation to do so.

I don't think we have anything like that in our code. We don't have tit-for-tat to start with, at least not in the sense it's described here.

There's definitely _something_ going on with a 11-12 second period and I strongly suspect it must be lockstepping because neither the router or the amuled machine are emitting congestion control packets when the spikes come in.


What do you see on _your_ router?