[e2e] YNT: A Question on the TCP handoff

Alper Kamil Demir demir at kou.edu.tr
Tue Dec 6 07:42:19 PST 2005

>What are SA1 and SA2 doing?
>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.

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

>> 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.
This is abvious as defined above.

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

>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.
>To make a long story short: When a TCP path changes, its state variables
>can change as well.
This is obvious. 

>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
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 on "warm-up connection" (between SA2 and FH).  When MH enters into cell of SA2 path characteristics are handed over/passed.

> >I still think that you try to keep state variables for a TCP connection
> >although its path changes fundamentally. And I´m not convinced that this
> >will work.
> That's correct. However, User Mobility Pattern (UMP) is proposed in our work. still not convinced?
We don't keed old state variables at all. New state variables are formed in advance according to UMP so that when MH moves into a new cell it has characteristics of new path. 

>Particularly, it would be _VERY_ hard to convince me of any kind of User
>Mobility Patterns.
I don't know what to say here, either :)

>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.
>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 admittedly tired of all those endless "stochsastic automatons" or
>"Markov Chains" etc, at least as
>each and any textbook on Markov Chains starts in the introduction with
>the remark, that
>reality is anything but markovian. And I´m tired to read, that some
>researcher has
>1. read this,
>2. understood this,
>3. ignored this.
I totally agree with you.

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

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

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

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

Alper K. Demir

More information about the end2end-interest mailing list