There's two types of data packets sent from BT client.
1. Tracker announce packets. (BT client identifier is in the User Agent field)
2. Peer communication packets. (BT protocol string + BT peer id + version is in the handshake packet)

I am going to concentrate on the Peer communication packets.

If encryption is enabled, the packets will be encrypted but we do know that RC4 encryption algorithm employed by the BT clients have been broken by HW. If rumours are to be believed, TM have bought those HW.

From Peer communication packets, theoretically all BT clients can be throttled since handshaking always contain BT protocol string. However, it seems like certain BT clients are not blocked which makes me suspect they are throttling based on BT peer id (which depends on the BT client you're using).

This could explain why some BT clients (e.g: Tootu) are working previously even though the famous big 3 have been blocked (Azureus, BitComet, uTorrent)

This method of throttling doesn't make a lot of sense since it is a lot easier to just block the BT protocol string. Of course, there's no reason to complain since it is working.
Btw, I have used Ethereal to check Deluge handshake packets and the BT protocol string is following the protocol.

Experiment(s) to run (I won't be running these since I have better things to do like BTing):
1. Will the connection be throttled if utorrent and Deluge is running at the same time? (This is to check if TM only target specific traffic and not the whole connection)
2. Capture Xunlei packets. (This is to check how Xunlei sends data. There are claims that Xunlei peer communication are done using HTTP packets which is not part of the BT protocols spec.)
3. Download Deluge torrent client tar ball and modify it to send utorrent BT client identifier, BT peer id and version. (Note that this is not a generally accepted practice since sending another client ID is considered client ID spoofing but for experiments only should be ok.)


BT protocol spec:
http://wiki.theory.org/BitTorrentSpecification

Ethereal download:
http://www.ethereal.com/

Copied this from Azureus wiki.
The handshake is seperated into 5 blocking steps.

1 A->B: Diffie Hellman Ya, PadA
2 B->A: Diffie Hellman Yb, PadB
3 A->B: HASH('req1', S), HASH('req2', SKEY) xor HASH('req3', S), ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)), ENCRYPT(IA)
4 B->A: ENCRYPT(VC, crypto_select, len(padD), padD), ENCRYPT2(Payload Stream)
5 A->B: ENCRYPT2(Payload Stream)

Assuming I understand the encryption algorithm correctly.
Assuming that TM can decode the encrypted stream. Possible points of failed decoding.
SKEY can be taken from tracker announces.
S from calculation of Ya, Yb.
IA is the handshake packet from A.

1. PadC and PadD being optional? But then if the B sends without padD then it should fail as well unless TM only checks handshake packets from A.
2. ???

Side note:
Tracker announces doesn't seem to be encrypted. IIANM.
Not that it will help if it is encrypted.


UPDATES:
I have checked Deluge Torrent code, PadC/PadD is always zero bytes so it's not that portion.
Anyone interested in changing the peer id and test out?