[e2e] YNT: A Question on the TCP handoff

Tue Dec 6 10:43:17 PST 2005

Alper Kamil Demir wrote:

...very
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
lines ;-)

Alper, it would be _really_ helpful if you could care for some kind of
linebreak.
I´m not familiar with this M$ stuff, you´re apparently using. However,
there should be some
kind of preference or option, where your MUA can be made to format lines
to some maximum length.
I personaly set my Netscape to a line length of 72 characters.

> 
> >What are SA1 and SA2 doing?
> >-Routing?
> >-Splitting?
> >-Spoofing?
> >In my former mails I asserted "routing".
> Synchronization of the "warm-up connection" and the "actual connection" is the responsibility of SAs that run in BSs. When SA is notified to establish a 
"warm-up connection", warm-up parameters, i.e., the current congestion
and flow control window sizes of the actual connection are also passed
to the SA.
> SAs are doing none of above (routing, splitting, spoofing). An SA establishes a "wam-up connection" before an MH moves into cell of SA so that characteristics of the new path is ready to be handed over or replaced by the old one. The term hand over might be confusing here. Any other suggestion is aprreciated.

Either way, there _is_ a TCP connection from SA2 to MH before the
handover occurs. Correct?
So, there _is_ a sender socket on SA2?

> 
> >> 1) There is a TCP connection ("actual connection") between MH and FH
> >> 2) Before MH moves into cell of SA2,  a new "warm-up connection" is established between SA2 and FH according to MH's User >>Mobility Pattern (UMP). (SA2 is  as much close to MH as possible)
> >Please define "close".
> "Being near in space and time". i.e. an SA is situated on BS as a middleware.

SA1 and SA2 are situated on two different BS, otherwise there would be
no need for handover. Is this correct?

> 
> >> 3) When MH enters cell of  SA2, "warm-up connection" becomes "actual connection" ( warm-up connection is handed over).
> >>     I am questioning if this is ever meaningful and/or possible?
> >I think, we should define the term "connection" here.
> I don't understand why you asked this question. I am talking about a TCP connection. It is defined in RFC793 as
>
>    [The reliability and flow control mechanisms described above require
>     that TCPs initialize and maintain certain status information for
>     each data stream.  The combination of this information, including
>     sockets, sequence numbers, and window sizes, is called a connection.
>     Each connection is uniquely specified by a pair of sockets
>     identifying its two sides.
>      ......
>     Since connections must be established between unreliable hosts and
>     over the unreliable internet communication system, a handshake
>     mechanism with clock-based sequence numbers is used to avoid
>     erroneous initialization of connections.]
> 
> >For me, a TCP connection has to endpoints.
                                ^^next try: two ;-)

> This is abvious as defined above.

Please correct me, if I´m wrong. But good ol´ RFC 793 does not know
anything about CWND and SSTRESH but defines the most basic
TCP algorithms. It does not take account congestion control. Is this
correct? This is no problem, because that issue was simply
not known when RFC 793 was written in 1981. TCP has seen some kind of
evolution since then.

> 
> >So, if we talk about state variables: In that case it doesn´t make sense
> >to keep the old state variables around the cell change.
> >However, the term "connection" wouldn´t make sense here, because it´s
> >not clear what a "warm up connection" from BS to MH is.
> We are nor keeping old state variabþes. Old state variables are replaced by new state variables obtained from "warm-up connection".

O.k.

Let´s talk about the congestion window CWND.

The congestion window probes / estimates the available storage capacity
available for a TCP flow along the path. (Once again: IIRC this
mechanism is _not_ discussed in RFC 793. It´s not 24 years old, 
it´s only about 16 years old. So we must look it up in some more recent
literature ;-))

In the old connection, CWND describes the fair share of storage capacity
along the path from FH to MH. It does not tell you where this
capacity is situated. E.g. most of the packets along the path may pile
up at the bottleneck which may be situated in the Internet
or in the wireless last mile, you simply _don´t_ know.

So, even if you would replace only the wirless part in your path and
would maintain the wired part, you would have absolutely
no idea about the correct value for CWND after the path change. Perhaps
you know some fair share of capacity from your 
"warm up connection". But which part of the former CWND shall be
replaced by this?
And with which sending rate are you probing? This depends on where the
bottleneck in your connecetion is situated.
This is one of the big mysteries in your connection: You have no idea
where the bottleneck is!

> 
> >If, however, a "warm up connection" means a TCP conection from BS to MH,
> >you would exchange components in Split connections.
> >Even in that case, the connection between FH and SA1 may be different
> >from that from FH and SA2.
> 
> If FH is sender [defined same as in RFC793], "warm-up TCP connection" is between SA (based on BS) and FH. Of course, they are different cause the paths might change.

O.k. And what does this "warm up connection" do? Particularly with
respect to CWND: How does it "struggle for space"?
In TCP, there is no rate probing but there is a struggle for space. As a
conseqence, a TCP flow will send with a certain rate.
And I intendedly say _struggle_. Because there is no "harmless probing"
which leaves other streams alone and obtains space
by miracle (Christmas is coming, jingle bells, jingle bells, jingle all
the way *sing*) but as soon as there are several
flows competing for ressources, there is a _struggle_. Even that is a
problem with a warm-up connection. Will it throttle
competing flows although it does not actually convey any data?

Again, this is not covered in RFC 793. (I don´t know the latest RFC
concerning TCP, but this is by far close to
a number like 3793 than 793.)

> 
> >CWND estimates the available fair share for a connection. CWND is
> >estimated on an end to end basis.
> >I don´t quite understand, how you will get a CWND from a warm up
> >connection.
> Whatever CWND means on end to end basis on a packet-swithed network, "warm-up connection" is established so that expected new path characteristics are formed 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Alper, you´re kidding, aren´t you?

<...>

> >There are tons of UMP around. The ones are bad, the others are worse.
> >Nearly all of them are proven
> >by repeated assertion or by assistance of God or something like that.
> We are using "Erdal Catirci, Ian F. Akyidiz, User Mobility Pattern Scheme for Location Update and Paging in Wireless Systems, IEEE Transactions on Mobile Computing". p. 236-247, ISSN:1536-1233, 2002.

I would appreciate a copy, if this is possible. (And as usual, we are
pleased that the citeseer system behaves at it is supposed to. It´s
down. :-( )

> 
> >First of all, UMP and paramter estimation appear to me as some
> >independent problems.
> >Second, when you want to convince me of a certain UMP, there is exactly
> >one way to do so:
> >You _must_ validate your model with _real_ observations, with
> >measurements from _real_ life.
> What is _real_?  ;))

I´m not quite sure, what is the real Detlef. *looking around*

I think about this for years now.

Actually, I come to the conclusion that we should define a number of
relevant scenarios. We should not _invent_ them. They must be
part of the real world. E.g. it will be hardly possible to describe
muser mobility or the C/I ration of a wireless channel
for the whole world. (I know about those papers who claim that. The big
waste basket in our house knows them as well.)

But we can investingate typical situations like "Germany, city with
about 500.000 inhabitants, downdown, 5.00 pm, pedestrian user".
So, we talk about the downtown areas of cities like Hannover or
Stutttgart (perhaps Munich? I don´t know the number of inhabitants,
but it´s a village that fit´s into this category.) We don´t talk about
Braunschweig or Halberstadt, and we don´t talk
about Hamburg or Berlin.

I´m quite sure that we will need several scenarios like that. Perhas we
need a scenario for Stuttgart, Hannover, Munich.
And then we need a more urban scenario. Hamburg, Berlin, Paris, London.

Perhaps, we need different time schedules, I don´t know. And then, we
can check whether real users behave like the model says.

Example.

For about nearly 6 years know I wonder whether delay spikes and spurious
timeouts in TCP are reality.
They exist in papers. _Without_ any kind of rationale where they should
come from or a justification why they are introduced.
There are only some very few observations (I think, Chakravorthy made
some in London) without any deeper analysis where
the observed "symptoms" result from.

Sorry. This is not convincing.

Show me, were a delay spike may come from and prove to me in
reproducible observations that this phenomen realy exists.
Afterwards, we can talk about the reasons for this phenomenon.
Anything else: => waste basket.

> >Admittedly, I did not yet read your UMP. (My blood pressure ;-))
> See above.

Be aware of my blood pressure ;-) At _your_ risk ;-)

> 
> >But once again: When we talk about a UMP, I only could be convinced,
> >when the pattern is
> >validated with reality. A pure "system model" (hopefully, one of the
> >then thousands of them
> >will mach reality or reality would change according to our system model)
> >is not sufficient.
> I assume this is a deep discussion.

Absolutely. But _science_ is a deep discussion. Or it´s not science.

> 
> >Perhaps this sounds somewhat harsh.
> It doesn't for me.
> 
> >It just reflects my own situation. For about several yeas now I think
> >about "interactions between L2 and L4
> >in mobile wireless networks."
> To me, all layers are "interacting". However, it is easily perceivable that L2 and L4 are "interacting" cause they are almost identical and parallel in functions but space/distance.
> 

It´s not that easy for me to see the interactions, particularly claimed
adverse ones. But I´m totally with you that L2 and L4 have pretty much
in common in some important aspects. E.g. a Radio Link Protocol in
mobile networks has some similarities with transport protocols.
It is quite interesting to see the similarities _and_ the subtle
differences which often become obvious not before a closer look.

> >And now, I´m desperately hoping for contradiction for the next sentence:
> >"There are none."
> "There are none" if and unless it is proved ;)))

That´s exaclty what I mean.

Unfortunatley, my mailbox is still empty. No one wants to kill me, no
one contraditcts me.
So, either nobody has read this sentence, or everybody ignored it.

Is there something like "prove by lack of contradiction"?

Detlef

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