Justin:
TCP window scaling is an inherent behaviour of the tcp protocol and the
parameter can be tunned.
Because you didn't references the devices involved in the problematic link
is very hard give you an opinion about the cause of the problem.
You mentioned the problem with the ingress shapping. Maybe is a problem with
different mtu crossing the frontier (e.g.: optical fiber to ethernet media)
or maybe is a problem in the traffic shapping itself (e.g.:bad
configuration).
In any event, I think that is not a good option "hacks" the protocol
inyecting packets to the tcp sessions.
Having a more information (like a traffic trace when the problem is
happening) will give us more elements to answer your question.
Jorge Dávila.
On Thu, 30 Aug 2007 12:45:43 +0200
Justin Schoeman <justin@xxxxxxxxxxxxxxx> wrote:
I have posted this before under another thread, but did not get many
replies. So I thought I would post it under a more appropriate subject.
OK, so we have a link that has a fair bandwidth, and a high latency. This
means that TCP windows get nice and big.
Now I have a problem with ingress shaping, because the current
implementation just drops packets. This means that we have to wait for the
sender to notice the packet drop (OK, or for the receiver to notice at out
of order inbound backet). But either of these can take quite a while,
during which the sender is still sending data at a rate higher than what
you want to throttle it to.
What I was considering was, instead of just dropping the packet, send out
an ACK packet (to the sender of the packet we are dropping), repeating the
last ack sequence, as recorded in the conntrack table.
This should be the second ack the sender receives, which should
immediately start a 'slow start' procedure, and get the sender to back off.
This is still as wastefull as just dropping the packet, but should have a
more immediate effect.
The problem is, how will the sender and receiver respond? They may now
receive a number of packets in completely unexpected order.
Is this practical? Will it work? Will it help?
Thanks!
Justin
Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@xxxxxxxxxxxxxxxxxxxxxxx
