[e2e] TCP Performance over WWAN

Detlef Bosau 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
> understood;

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.

In theory.

How is this achieved practically?

> So attempting to retransmit a packet makes sense.
>
> The problem is, how many times?

Exactly. Q1.

>   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
> damaged).

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.
<rant>
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 
carriers.

2.: Besides ignoring these problems and leaving the to lower layers, 
there is an attitude not to publish on these problems.
</rant>

 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 
are achieved?
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 
recommendations.

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 
Berlin.

(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 
problems.....)

(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 
Washington Post.
http://www.washingtonpost.com/wp-dyn/content/article/2010/09/30/AR2010093003592.html
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.

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------




More information about the end2end-interest mailing list