Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage
AppWard and ExitWard indicate the direction of cell flow through the circuit. Previous cell events aggregated statistics for both directions and therefore did not capture information which I believe may be important. These are much more informative than N and P. Do you have suggestions for improving this further?
Ahhh, gotcha. Personally I'd go for 'inbound' and 'outbound' since they better connotate directionality. AppWard and ExitWard sound weird, but they make sense now too and would be fine if CELL_STATS got a quick description saying what they mean.
On 2/12/13 4:54 PM, Damian Johnson wrote:
AppWard and ExitWard indicate the direction of cell flow through the circuit. Previous cell events aggregated statistics for both directions and therefore did not capture information which I believe may be important. These are much more informative than N and P. Do you have suggestions for improving this further?
Ahhh, gotcha. Personally I'd go for 'inbound' and 'outbound' since they better connotate directionality. AppWard and ExitWard sound weird, but they make sense now too and would be fine if CELL_STATS got a quick description saying what they mean.
Sure, I'm fine with calling it 'inbound' and 'outbound'. Will change that the next time I touch the proposal. Thanks! I also thought more about Rob's idea to link circuits from client to exit in a testing network. I think we should add two more fields InboundName and OutboundName to CELL_STATS events. These fields would contain LongName ($CC88FB3B78599580F1EE4F6F73E26A7EC3DF2CA1~tokenconn) or Target (like 60.1.0.0:10002) of the previous or next node in a circuit. While it may be possible to extract this information from ORCONN events, that seems somewhat fragile to me. (When testing this, I had a case when we were missing ORCONN events, because the controller was not yet connected, so it was unclear where the CELL_STATS events belonged.) Here's an example of the extended CELL_STATS event (still using positional arguments, because I didn't change the code there yet): CELL_STATS 48957 15 $9441269F5989487F07AE824063345A0A6BCAB279 created=1;relay=1 created=1;relay=1 created=0;relay=0 29201 16 $DC284D0012ECB812C0CA2DEB080CB2F839A77E1A create=1 create=1 create=0 And here's how we'd put together relevant CELL_STATS events to learn what happened in a given circuit: [fileclient-60.1.0.0]:[tokenconn-59.1.0.0]:34760 00:23:16 [fileclient-60.1.0.0] >>> circ=34760 conn=12 create_fast=1;relay_early=2 create_fast=1;relay_early=2 00:23:16 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1;created_fast=1 relay=1;created_fast=1 00:23:17 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1 relay=1 00:25:01 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1 relay=1 00:25:01 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay_early=1 relay_early=1 00:25:02 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay_early=1 relay_early=1 00:25:02 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=6 relay=6 00:25:03 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=40 relay=40 00:25:04 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay_early=1 relay_early=1 00:25:04 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=61 relay=61 00:25:05 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=1;relay_early=3 relay=1;relay_early=3 00:25:06 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1 relay=1 00:25:06 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=1 relay=1 00:25:07 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=44 relay=44 00:25:08 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=63 relay=63 00:25:08 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=3 relay=3 00:25:09 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=2 relay=2 00:25:10 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1 relay=1 00:25:10 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=1 relay=1 00:25:11 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=94 relay=94 00:25:12 [fileclient-60.1.0.0] >>> circ=34760 conn=12 relay=4 relay=4 00:25:12 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=12 relay=12 [tokenconn-59.1.0.0]:[tokenglobal-57.1.0.0]:9272 00:23:16 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 create=1;relay_early=1 create=1;relay_early=1 00:23:16 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 created=1;relay=1 created=1;relay=1 00:25:01 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay_early=1 relay_early=1 00:25:01 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=1 relay=1 00:25:02 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=6 relay=6 00:25:02 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay_early=1 relay_early=1 00:25:03 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=41 relay=41 00:25:04 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=60 relay=60 00:25:04 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay_early=1 relay_early=1 00:25:05 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=1;relay_early=3 relay=1;relay_early=3 00:25:06 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=1 relay=1 00:25:06 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=1 relay=1 00:25:07 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=52 relay=52 00:25:08 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=1 relay=1 00:25:08 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=55 relay=55 00:25:09 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=4 relay=4 00:25:10 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=1 relay=1 00:25:10 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=1 relay=1 00:25:11 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=98 relay=98 00:25:12 [tokenglobal-57.1.0.0] <<< circ=9272 conn=15 relay=8 relay=8 00:25:12 [tokenconn-59.1.0.0] >>> circ=9272 conn=18 relay=4 relay=4 [exit1-61.1.0.0]:[tokenglobal-57.1.0.0]:38910 00:23:16 [exit1-61.1.0.0] <<< circ=38910 conn=24 created=1 created=1 00:23:16 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 create=1 create=1 00:25:01 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=1 relay=1 00:25:01 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay_early=1 relay_early=1 00:25:02 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=30 relay=30 00:25:02 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay_early=1 relay_early=1 00:25:03 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=77 relay=77 00:25:04 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay_early=1 relay_early=1 00:25:05 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=1;relay_early=3 relay=1;relay_early=3 00:25:06 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=1 relay=1 00:25:06 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=1 relay=1 00:25:07 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=80 relay=80 00:25:08 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=27 relay=27 00:25:08 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=1 relay=1 00:25:09 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=1 relay=1 00:25:09 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=4 relay=4 00:25:10 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=27 relay=27 00:25:10 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=1 relay=1 00:25:11 [exit1-61.1.0.0] <<< circ=38910 conn=24 relay=79 relay=79 00:25:12 [tokenglobal-57.1.0.0] >>> circ=38910 conn=27 relay=4 relay=4 I think this works for all circuits. Rob, what do you think about extending the CELL_STATS events as described above? Also, do we still need the ID= in ORCONN events if CELL_STATS events are sufficient to reconstruct circuits? Finally, Rob, should I look into CIRC_BW events you suggested a while ago? If yes, what did you have in mind how that event would look like, and when/by whom would it be emitted? Best, Karsten
I think we should add two more fields InboundName and OutboundName to CELL_STATS events. These fields would contain LongName ($CC88FB3B78599580F1EE4F6F73E26A7EC3DF2CA1~tokenconn) or Target (like 60.1.0.0:10002) of the previous or next node in a circuit.
Maybe it would make more sense to have an InboundName/OutboundName field for the LongName and InboundDestination/OutboundDestination for the address/port? In general overloading the type that a field can have isn't a good idea.
On 2/19/13 5:45 PM, Damian Johnson wrote:
I think we should add two more fields InboundName and OutboundName to CELL_STATS events. These fields would contain LongName ($CC88FB3B78599580F1EE4F6F73E26A7EC3DF2CA1~tokenconn) or Target (like 60.1.0.0:10002) of the previous or next node in a circuit.
Maybe it would make more sense to have an InboundName/OutboundName field for the LongName and InboundDestination/OutboundDestination for the address/port? In general overloading the type that a field can have isn't a good idea.
In general, I agree. Here, I re-used the code that adds a LongName or Target to CIRC events. It's a single function call that returns the best information tor has about the remote end of a connection. My idea was that controllers that can parse CIRC events can re-use that code to parse these fields in CELL_STATS events. Does that make sense? Best, Karsten
In general, I agree. Here, I re-used the code that adds a LongName or Target to CIRC events. It's a single function call that returns the best information tor has about the remote end of a connection.
I'm not sure that I follow. Do you mean the Path attribute of CIRC events? If so then that's just documented as being a list of LongName (or ServerID in older versions)... https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1271 I'm not spotting anything that is overloaded as being both a LongName and Target.
On 2/20/13 5:13 PM, Damian Johnson wrote:
In general, I agree. Here, I re-used the code that adds a LongName or Target to CIRC events. It's a single function call that returns the best information tor has about the remote end of a connection.
I'm not sure that I follow. Do you mean the Path attribute of CIRC events? If so then that's just documented as being a list of LongName (or ServerID in older versions)...
https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1271
I'm not spotting anything that is overloaded as being both a LongName and Target.
Err, I meant ORCONN, not CIRC. "650" SP "ORCONN" SP (LongName / Target) SP ORStatus [ SP "REASON=" Reason ] [ SP "NCIRCS=" NumCircuits ] CRLF
Gotcha. I'd still advise against it. Controllers can certainly parse that kind of response, but it sucks for users. Stem's ORCONN event handling is suckier than most because of it. https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/response/events.py#l6...
participants (2)
-
Damian Johnson -
Karsten Loesing