Throttling, MTU and fragmentation
In December last year Rich Riendeau reported excessive packet fragmentation from the throttling implementation in Charles v2.6.1. While the simulation of the bandwidth was accurate, it didn’t necessarily reflect the structure of the packets as they would actually exist on the network in a bandwidth limited situation.
Packets are usually be sent out onto the network in fragments equal to the MTU, however Charles tried to share the throttled bandwidth between multiple connections by allowing data through in chunks of approximately 1/10 of the available bandwidth. Therefore depending upon your throttling configuration, and the number of concurrent connections, Charles could produce more packet fragments than would be expected. So as of Charles v2.6.2 the throttling system has been tweaked to use MTU-size packets.
As a consequence of this there is an MTU setting as part of the throttling configuration. On a broadband connection (and on any Ethernet network) the MTU is often 1500 bytes, however on a modem or PPP connection the MTU is 576 bytes and packets must be fragmented to fit. Charles now has the capability to simulate the MTU differences on different types of connections and thus effect the appropriate realistic fragmentation.
Looking to the future: a feature that has been requested a few times is random throttling to simulate variable Internet conditions. I’ve spoken to several people about it and I think that its time may be near! If you’ve got any thoughts about it I’d be pleased to hear them.
April 7th, 2007 at 12:24 pm
Karl … “parsimony” came to mind. I’m wondering, would a principled practitioner here invest resources in generating a random function? I haven’t walked down this path in a long time, and it’s tickling my brain.
If a simple mechanism was used (look up table) that resulted in arbitrary and sudden deviations … rather than cycling of some sort (I remember troposcatter signal reflecting rainfall along the path) … would that meet the need?
I have to find something to program!
–bentrem