[e2e] end2end-interest Digest, Vol 19, Issue 5

[Detlef Bosau]

> Thierry Klein wrote:
> >
> >
> 
> We have investigated opportunistic scheduling and their impact on TCP
> and shown that scheduling can indeed cause spurious timeouts (in
> particular if the PF scheduling algorithm is considered). We have also
> proposed a modified scheduling algorithm to include the first and
> second moments of the inter-scheduling interval in the scheduling
> decision.


Having not yet read your paper (I will do so as soon as possible,
unfortunately I have not yet access to the paper), one question is:
Should we really modify the _scheduling_?

Basically, this is nothing specific to mobile wireless networks. Some
ages ago (not to much, something in between :-)) "Multimedia over IP
networks" was modern. 
(Admittedly, I´m not a multimedia guy.) 

When I implement QoS in packet switching networks, I will always have to
obey my QoS contracts. And then I can put the rest on the network.
First, QoS is served, best effort is left for the rest, or the rest is
left for best effort. So, my first question is: Does changing the
scheduling algorithm affect QoS traffic / voice traffic etc.? If so,
this would hardly be accepted by cell phone users, as they pay
their operator for making and receiving phone calls.

However, basically I´m fixing my big picture. And at the moment, my big
picture is:
1.: Spurious timeouts are not really an important issue. They are at
least that rare that they cause no big harm.
2.: If they occur, there are knwon techniques to overcome them or to
deal with them. You can use an approriate ARQ scheme which "spreads"
delays about several packets, you can use PEP (I-TCP, Dumb Spoofing,
ReSoA, whatever you prefer), you can use TCP/Eifel to alleviate the
effects a posterirori,
you can increase your RTO, perhaps you choose RTO=E+50*V in Jacobson´s
algorithm, when you want to avoid unnecessary delay in necessary
retransmissions,
refer to RFC 3517 or RFC 3782.

Some basic lesson I learned during the last few weeks, especially from
Mark Allman is: 
1. Timouts are a mess. Period. (This was written earlier by Lixia
Zhang.)
2. If there is a mess, we should clean up.

So, I will sharpen this somewhat: We can replace VJ´s algorithm by 
RTO = E + 100 * V + 5 minutes spare time and use the aformentioned RFC
for loss detection.

There are some cases, where this cannot be done or where this is
somewhat unfortunate. I´m not ready with this. I still learn and try to
understand.
In theses cases, timeouts are a last ressort and thus are a necessary
evil.

At least, and I admit Mark Allman made me shake and tremble there, for
me the question arose: What´s this whole RTO debate good for?
For _me_ it´s good because I learn a lot.

When I sometimes sharpen things, it´s perhaps my "nature", my way of
thinking. However, my _basic_ intention at the moment is to understand
things.
And one thing, I´ve learned is that the timeout debate is basically
closed and well understood. Perhaps, we can create scenarios
where spurious timeouts occur. However, basically it´s not that
worthwile. It´s however always a good idea to have a certain repertoire
of approaches
handy, if someone raises the "spurious timeout issue" in a discussion.

However, when I return to my own initial question: "Is there a problem
with TCP in mobile wireless networks?" I learned: If there is one,
it´s certainly not (longer) the (spurious) timeout debate. Perhaps we
can make some minor improvements there, but basically the issue is
understood. So, I will fix my big picture and look for the next problem
:-)

Science is like a colouring book :-) You always look for pages which no
one has painted before :-)

Detlef
-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937