<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/24/2013 02:44 PM, E.S. Rosenberg
wrote:<br>
</div>
<blockquote
cite="mid:CAHTx_BOamf8t8+YYgwfMmiQUFcnm7CuEuT8QH8BPqy0kqkKZBQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<pre>When you enable timestamps they don't match so the packet is discarded, this could be due to the ISP fiddling with the packets on the way.
</pre>
</div>
</blockquote>
I know what timestamp is, and what it is used for. I have not, yet,
rebooted to see whether this does not happen when the problem is
dormant. What I told Shimi was that I want as much information as
possible, and since he seems to know a bit about it, I would like to
hear it all.<br>
<br>
It is not enough to say "the ISP is fiddling with the packets". I
want to know fiddling how. Changing the timestamp might be done by
some brain-dead QoS in order to fool the TCP congestion mechanism.
In my case, the timestamp moved backward by 2948. This might be done
by a traffic shaping mechanism in order to make the RTT seem longer,
and thus give them more time to do other manipulations of the
traffic.<br>
<br>
One example is, if they want to slow down the connection, they need
to make the rount trip time seem longer. Otherwise, my TCP/IP stack
might assume that the packet was lost, and perform a retransmit. If
you bear in mind that they are after reducing my bandwidth usage,
you will see how that is bad for them.<br>
<br>
So, as you can see, there are valid reasons to find out not just
what is happening, but also why, before I call and yell at them.<br>
<br>
Shachar<br>
<pre class="moz-signature" cols="72">--
Shachar Shemesh
</pre>
</body>
</html>