[e2e] YNT: A Question on the TCP handoff

[Detlef Bosau]

"Atiquzzaman, Mohammed" wrote:
> 
> You could check our SIGMA mobility management scheme at 
> http://www.cs.ou.edu/~netlab/sigma.html which uses L2 information 
> to carry out a L4 handoff.  Use of SCTP has also solved many of 

Very stupid qeustion:

What is L4 handoff?

Perhaps I suffer from a somewhat old fashioned way of thinking. But for
me, the Internet is a packet switching
internetwork. Hence, a "connection" in TCP is a purely virtual entity.
The path between sender and receiver
is fully transparent, the locations of sender and receiver are fully
transparent to each other.

Now, when a path _changes_, this is hardly transparent. But this is a
matter of fact. And no scientific problem.
When a path consists only of 1 GE lines and after a path change there is
a 2k4 modem line somewhere in between,
perhaps the rate may drop. Perhaps the RTT may increase. Perhaps CWND
and SSTHRESH will change.

In short terms: TCP will adapt.

So: _Where_ is the scientific problem?

> the cwnd related questions raised earlier in the thread.  

I cannot follow.

To my knowledge, SCTP is used for media streaming. Is this correct? So,
we are more or less in an environement where
QoS considerations apply.

The Internet is a best effort network.

Let me state my question in another way:

What is the scientific problem in a path change (MH roams) compared to a
reciever situated in a CSMA/CD network in an office at about
9.00 am, when the employees start working and switch on their computers?

There may be a load peek.

There may even be a noise peek because of poor power supplies used with
the computers which interferes with the local Ethernet.

But is there anything what cannot be successfully delt with by TCP as it
is?

When your car stops on a highway due to a lack of fuel, this is no
reason to go for a PhD. It´s a reason to go for petrol.

Your solutions and all the others may be fine. But my question is still:
Are there _hard_, _structural_ problems resulting
from L2/L4 interactions in wide area mobile networks like GPRS or UMTS? 

It´s no question that there are perhaps some technological issues. It´s
no question that there are perhaps noisy lines and this
can hinder communication. (When I pull out the etherner plug from my
computer, this will hinder commonication as well.)

To give a concrete example. Four quite a couple of years, we are talking
about delay spikes and spurious timeouts now.
(BTW: These are no problems for TCP in recent flavours, because packet
loss is typically not detected by timeouts except
from some rare situtaions, IIRC e.g. at connection shutdown or perhpas
in extremely short termed flows where at least SSTHRESH will not settle
anyway and the discussion itself is quite meaningless.)

We´ve seen "hiccup" tools to introduce arbitrary latencies into
simulated TCP connections.

Fine.

Question: Do spurious timeouts happen in reality?
Do delay spikes happen in reality?

What are the _reasons_ for delay spikes? Besides of e.g. moving behind a
wall of ferroconcrete, because this is once more the problem with
the car and the petrol.

Perhaps, the question must be put the other way round:

In which scenarios TCP is _supposed_ to work? And what is the meaning of
"supposed to work"?

Is TCP supposed to work when the mobile user jumps into a swimming pool?
Is TCP supposed to work when the mobile user runs out of battery power?
Is TCP supposed to work with 10  Gbit/s throughput on a GSM line?

With respect to roaming: I myself use a mobile phone for about 10 years
now. And I never perceived any annoying effects from roaming,
when I made a phone call. So, even granted there would be some smoothing
and some tricky mechanisms in dealing with speech, any kind
of roaming will hardly interrupt the line for more than, say, 0.1
seconds.

Do you know of _any_ TCP(sic! no real time media streaming!) application
which cannot deal with an interruption of 0.1 seconds?
I don´t.

One day, some guy told me of 42 seconds reattach time after a total cell
loss in GSM. O.k. So you pulled out the Ethernet plug
with your feet and now you will have to crawl under your desk in order
to have it reinserted. The first one is a design decision
in GSM, the second one is a problem with your feet. Is this a problem
for TCP? No. I don´t see that TCP is supposed to
work with broken links and unreachable peers. And I´m not fully
convinced that TCP modifications will help here.

>From what I understood from TCP, TCP will adapt to different path
characteristics. If a path changes, due to roaming or due to a route
change
or due to a failover or whatever, TCP will adapt to the changed path
characteristics. At the moment, I don´t see any real problem.

I could even look into literature.

Bakre/Badrinath talk about some issues in WaveLAN handover. (I-TCP). I´m
not quite sure whether roaming between different base stations
in Wave LAN was supported that time. In addition, I-TCP adds some local
recovery layer here. But which _problem_ is solved?

Balakrishnan (Snoop) enlightens us with the benefits of local recovery
on lossy links. Not that new of course, but: Repetitio est mater
sapientiae.
(Yes, of course, there is some problem discussed with duplicate
acknowledgements on L4 resulting from some unfortunate RLP
implementation.
 I don´t know any RLP implementation in mobile networks which ever
suffered from that problem.) 

This is all fine. And it´s all interesting.

But did these approaches solve, even _discuss_ structural questions?
What were the _new_ lessons learned here?

Perhaps my impression is totally wrong here. But many of the work I´ve
read so far does not teach us new lessons (well taken into 
account the time when the work was written) but tells us funny things
which are nice to have.

And concerning TCP in mobile networks, the essential lesson is, what we
all know for years: TCP will work not better than the path allows.
If the path is fine, TCP will work fine. If there is no path, TCP will
not work.

I intendedly don´t say anything about the loss differentiation debate.
Either a network link is (nearly) loss free or one would
introduce a local recovery layer there. So, I don´t see the problem
here.

It´s perhaps a personal problem of mine. I was totally convinced of the
existence of a pletora of problems here. But the more I think
about it, the more I question problems of TCP in mobile networks the
less problems persist.

Perhaps, it´s not realistic to expect some scenario which is a)
realistic and widespread and in which b) the whole community
will shout: "We do not yet know how to deal with this situation!"

Roaming is certainly not a scenario like that.

In my honest opinion and in my experience, roaming in mobile networks
simply works. Period.
And as it´s not broken, we don´t need to fix it. When you have full
coverage, you could take your mobile and walk from Stockholm to Bukarest
and talk, surf, all the time, you will most likely not notice even one
cell change. With actually existing techniques and approaches.
O.k., Let´s take Paris to Moscow. It´s perhaps better known outside
Europe ;-)

(To "Europeans living overseas": Paris and Moscow are continental
locations. *SCNR*)


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