Too Much Bandwidth Consumption.

[asterdeve]

Dear, Sir, I am using this tunnel about 2 month since that time I notice that its consumed very much bandwidth, I using this mostly for VoIP Trunking, without this tunnel my Bandwidth Usages is approximately 2.5GB - 3GB maximum & sing I am using udp2raw-tunnel the usage raised to 10-12GB. which unexpected.

Please if anyone one or anyone face same issue then please let me know how can I fixed it or if its possible to fixed. T.I.A

[wangyu-]

udp2raw use hartbeat to monitor the health of connection. the extra traffic is mainly caused by heartbeat.

Currently the only way to reduce traffic caused by heartbeat is to use the --hb-len option, the smaller the value the less traffic used.

In furture I will consider expose more heartbeat tunning options.

[stark131]

any update on this hearbeart length issue? actually udp2raw sends the heartbeat every 600ms by default, which is not necessay. Can you expand it to like 15s or 20s?

[Notselwyn]

Any update on this matter? I think an heartbeat every 15s would be appropriate as well.

Edit: just tested and it and looks like the heartbeat is required to keep the connection open so it needs to be fast

[LindaFerum]

@Notselwyn @wangyu- Sorry for disturbing but I have to wonder... is this a TCP proper thing, fakeTCP implementation thing or NAT thing ?

common TCP keepalive frequency I've seen in use (on "non-fake" TCP systems though) is like one every 15-20 minutes.

Is there something about fakeTCP ("simulate an almost real seq/ack procedure"?) that requires radically more frequent heartbeats?

Because if it is purely to handle NAT then I can sacrifice NAT punchiness for less traffic consumption / less battery use on some of my devices (mobile)

[wangyu-]

common TCP keepalive frequency I've seen in use (on "non-fake" TCP systems though) is like one every 15-20 minutes.

I don't think 15-20minutes is common, most values I saw are <1minutes

Is there something about fakeTCP ("simulate an almost real seq/ack procedure"?) that requires radically more frequent heartbeats?

No. The default value is just my personal preference.

I didn't provide a command line argument to change it, since I think the use case to change it is not common enough.

But in the case if you seriously need to change it, you can change the heartbeat_interval in misc.cpp to control the frequency. Also you might need to change client_conn_timeout accordingly.

[LindaFerum]

Thanks for the explanation @wangyu- One more question, if I have a process that regularly polls a remote server unrelated to UDP2RAW (specifically, MicroG on android polling Google's cloud messaging servers) every 5 minutes, would it be reasonable to expect it to behave like a normal keepalive for purpose of UDP2RAW behavior

What I mean is something like

1) My microG is configured to poll every 5 minutes

2) I set UDP2RAW's heartbeat_interval and client_conn_timeout to something much longer, say 45 minutes

3) connection with UDP2RAW endpoint dies 4 minutes in (bad luck, roaming, some silly NAT/router business in between, whatever)

4) MicroG polls on 5th minute, detects no response and tries to re-establish connection

Would UDP2RAW's behavior at step 4 be analogous to "keepalive failed" behavior (attempt to bring up new connection to UDP2RAW endpoint, which would be intuitive) or would there be some intricacies involved?

[wangyu-]

polls a remote server unrelated to UDP2RAW

not sure what you mean by "unrelated to udp2raw", but if you want to keep udp2raw alive, you have to poll through udp2raw.

I set UDP2RAW's heartbeat_interval and client_conn_timeout to something much longer, say 45 minutes

First,  

heartbeat_interval means how often you send heartbeat,  client_conn_timeout means how long till the connection is considered lost.

The client_conn_timeout needs to be reasonably longer than heartbeat_interval. Did you set them correctly? If you still don't understand how to set them, take a look at the default value, and scale them up proportionally.

Second,  

If you want to change the heartbeat to 20s then heartbeat_interval  client_conn_timeout should be sufficient.

But if you want to change it to 45mins,  it breaks more assumptions inside the udp2raw. You will also need to change some other values as well.

For example conv_timeout which means how long does a session/connection inside udp2raw time out.  (in contrast client_conn_timeout means how long does  udp2raw client consider itself to lose connection from server).

But I don't guarantee changing conv_timeout is sufficient.   Since you are trying to change the parameters beyond the value udp2raw is designed to work with.  I suggest you go through the code and check what else needs to be changed. 

[LindaFerum]

@wangyu- thanks! " if you want to keep udp2raw alive"

I guess that answers my question, I can't rely on services running "behind" UDP2RAW to keep the connection with their own keepalives. Hm.

I guess I should consider how my android's internals (two microG instances, one in main profile one in work profile) are setup first and then work from there...

Thanks again!