[e2e] TCP Performance over WWAN
detlef.bosau at web.de
Wed Aug 24 19:33:57 PDT 2011
I would like to restart the discussion from this point on, because the
discussion did not yet come to an end.
(More precisely: It did not even start.)
On 08/14/2011 06:43 PM, Jim Gettys wrote:
> Problems are very real and cause real grief; these stem from both
> everyday bugs and mis-understandings on all sides of when packets should
> be dropped, and when retransmitted at the link level (which has much
> more information about how lossy the channel is this instant than the
> end hosts can possibly have).
O.k., I'm afraid, you're correct here ;-)
> The situation is therefore more complex than I had originally
This matches my experience from the last 10 years.
> both from the nature of the beast (wireless) and those
> caused by aggregation (802.11n will aggregate multiple packets into the
> same wireless frame). I expect most people on this list had the same
> kind of naive views I started with.
> Here's quick, buggy synopsis as I understand it:
> In 802.11, you can be by far better off (taking less time on the scarce
> resource, the wireless channel) attempting to retransmit a packet at the
> high rate you are attempting to transmit it at than try to drop the rate
> to something lower and retransmit the packet in the face of failure; in
> fact, the lower rate may in fact be worse than the higher rate. It may
> be much better to try to transmit the same packet conceivably even 5 or
> 10 times than to have to drop to a low rate (which may work even worse
> due to multipath).
Fine. The problem is:
First: When you retransmit the packet: How often should this be done?
Second: When alternative rates are available: How do you choose one?
Of course, you could ask Q to hold on stardate, make 10 PhD students
investigate the problem and make a proposal, then you can take a
decision and ask Q to let stardate continue.
How is this achieved practically?
> So attempting to retransmit a packet makes sense.
> The problem is, how many times?
> And when do you give up and try
> something different?
When do you give up? Q2.
What do you try instead? Q3.
> And eventually, you really must drop a packet (or
> mark with ECN) to slow down the transmitter).
This leaves layer 2. However it raises the question:
Does the layer 2 behaviour affect higher Layers? Q4.
If so: How? Q5.
If Q5 is answered and we have adverse effects: Can these be alleviated, Q6
and if: how? Q7?
> With aggregation, some packets may get through, and others be damaged
> (802.11n gives you a bit mask telling you which are intact and which are
Aggregation may worsen the situation for TCP, because packets on
different channels (if you aggregate independent channels) my need
different times for transport and hence packet order distortion may occur.
Unfortunately, up to now, I've seen two positions on these questions.
1.: These problems are solved, particularly they are no computer science
problems and hence should be left to these idiots with the soldering
gun. TCP works anyway, it even works (practically proven!) over avian
2.: Besides ignoring these problems and leaving the to lower layers,
there is an attitude not to publish on these problems.
From existing WWAN standards, e.g. GPRS, I know, that users are offered
the possibility of so called QoS parameters. (Sometimes called rosary or
holy water, you could even ask St. Ignucius to borrow his halo....)
Now, an SDU corruption ratio 10^-3 may appear reasonable in this context.
However, promising SDU an SDU corruption ratio 10^-9 sounds funny :-)
Some weeks ago, a colleague asked whether I had an idea, how these
ratios were achieved.
Admittedly, my excuses were quite vague...
So, perhaps, one question is: Do we _have_ an idea, how rates like these
Do we _have_ an idea, to which degree packet loss should be treated
locally? (Yes, we have the paper by Salzer et al., that we should think
about it and not do too much retransmission. So, the maximum of accepted
retransmissions is 3. I think, we can agree upon that. The question
remains: What is the correct value for 3?)
Sometimes, I think that our understanding of these problems is somewhat
vague, particularly I did not find papers with real hard facts and
Actually, there are scenarios which simply work. This is achieved by
biofeedback adaption: If it doesn't work, stop the bloody thing and try
it again next Thursday.
Or stop the bloody thing and try it again at a different location.
Or stop the bloody thing, take a decision and delegate it to some other
person. Who will fix the problem because you have so decided.
On the one hand, e.g. mobile phones work quite fine. On the other hand,
an acquaintance of mine gave me about 15 calls yesterday in the evening,
and I don't remember exactly, whether we talked 10 words or 12. There
was a certain problem with the network coverage somewhere in the city of
(That's the difference between Berlin and Stuttgart: In Berlin, you may
have a problem to access a network because of coverage problems, in
Stuttgart you may have problems catching a train because we cannot
decide where to place the train station. There is a transitive
extension. If you travel to Stuttgart by plane, you will perhaps
encounter a problem how you will travel to Stuttgart from the airport.
At least, an attempt to travel by train may lead to well known
(Meanwhile, the problem worsened significantly, because we cannot decide
whether we should destroy the old train station or whether we should not
build a new one afterwards.)
O.k., that is not a topic for this list, besides, perhaps, the note that
conferences (on whatever, networks included) are quite unlikely to take
place in Stuttgart for the next future.
(For those who have no idea what I'm talking about: Refer to the
And the story still continues...)
Therefore, achieving progress in wireless networking would greatly
alleviate the situation because we could at least communicate then - if
there is no possibility to travel.
O.k., back to our issue. I'm still looking for a point to start to get
at least a reasonable model for the situation and to achieve a sound
assessment whether particularly TCP will encounter problems in WWAN or
not and if: how can these be solved?
However, before we solve them we must _know_ them.
There are many statements of belief in this area.
However: I really miss the hard facts.
(Although we have sound solutions of quite some few important particular
problems or some restrictive assumptions on the system respectively.)
I really would appreciate any discussion in this field.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest