[e2e] end2end-interest Digest, Vol 19, Issue 5
detlef.bosau at web.de
Thu Sep 8 16:32:48 PDT 2005
> 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
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
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
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
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
In theses cases, timeouts are a last ressort and thus are a necessary
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
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
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 :-)
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest