[e2e] YNT: A Question on the TCP handoff

[Alper Kamil Demir]

>...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.
Sorry for the unreadable mail. However, I am not sure if this readibility issue concerns I or You. 
Cause, I am using Microsoft Outlook Web Access (OWA)/Internet Explorer 6.0 suite to access
my email and this suite has no "quoted-printable" features to be configured by an end user as far
as I know.  (do not ask me why ;)
In order to be helpful, I will "line-break" myself so that any MUA not supporting line
wrapping could view. However, putting self line lengths has also its own problems such as short
and long lines . 

>Either way, there _is_ a TCP connection from SA2 to MH before the
>handover occurs. Correct?
>So, there _is_ a sender socket on SA2?
Ok. Let's clarify what are SA1 and SA2 doing?. Let's draw your reference network again:

 |------------------------Actual  TCP connection ------------------|
FH ------Internet-------!!!! wireless network  !!!! SA1 !!!!! MH
                                      !!!!wireless network  !!!! SA2  !!!!!
Please note that SAs are based on BSs.
 
1) There is a TCP connection between MH and FH.
     - if MH moved into cell of SA1 after it had established an "actual TCP connection", ignore this 
        situation for now cause the answer is in the next steps.
2) According to UMP SA2 establishes a "wamp-up connection"
 |------------------------Actual  TCP connection ------------------|
FH ------Internet-------!!!! wireless network  !!!! SA1 !!!!! MH
                                      !!!!wireless network   !!!! SA2 !!!!!
|---------- Warm-up TCP Connecion -----------------|
 
3) When  MH moves into cell of SA2 area, warm-up connection is handed-over.
  
FH ------Internet-------!!!! wireless network  !!!! SA1 !!!!!
                                      !!!!wireless network   !!!! SA2 !!!!! MH
|------------------------Actual  TCP connection ------------------|

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

> >I think, we should define the term "connection" here.
[My reply on the definition of "connection" goes here from RFC793.
>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.
I referenced RFC793 in order to give the definition of "connection"; NOT "congestion" 
cause you asked me to define it. I think there is a big misunderstanding. I am familiar with
TCP Congestion control. Yes, what you have stated above is correct, but not related to
why I wrote for. 
I am not sure if this issue was known in 1981, however somehow my memory calls that
it was a known issue before 1981. I somehow remember a related thread on e2e.

>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 ;-))
;))) I don't know what to say here. Once again, I referenced RFC793 in order to define the  term
"connection"; NOT "congestion". 
A start on the congestion control would be the V. Jacobson's SIGCOMM'88 paper and S. Floyd's
home page at ICIR has a very good and orginized related enhancements and recent literature.
To me, the recent literature is refinements on the SIGCOMM'88 paper.

>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. 
Was there CWND in the old TCP at all? (whic old are we talking about; RFC793?)
 
>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.
In our approach, we are ignoring this last mile from BS to MH. Is this really matters too much? 

>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?
Not the whole wireless part. Only the last mile from MH to BS. I mentioned this above.
We plan to chane the whole former CWND part. isn't this possible at all, is this against
the TCP end-to-end semantics? or not possible at all?
 
>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!
Sending rate? TCP is window based; not rate base. If bottleneck is not on the last mile
from BS to MH, we get the most accurate result.

>O.k. And what does this "warm up connection" do? Particularly with
>respect to CWND: How does it "struggle for space"?
The duration of "warm-up connection" is low. it struggles the same way of other TCPs.

>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.
It doesn't last long and handed over when MH moves into the cell area.

>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. 
I don't understand this part at all. It will harm for a short of time and the bandwidth it requires
is quite negligible.
 
>Will it throttle
>competing flows although it does not actually convey any data?
Yes, it will but it will convey dummy 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.)
Others are enhancements.Semantics is kept the same as it was.

> 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?
No I am not.  Could you define me what is "an end-to-end congestion control on a packet-switched network"? 
In the second part of the sentence, I mean, "warm-up connection" obtains the characteristics of the new path whatever
a TCP connection server up for. 
I don't see any kidding here.


>> We are using "Erdal Cayirci, 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. :-( )
I will send it to you

>I´m not quite sure, what is the real Detlef. *looking around*
>I think about this for years now.
Me too.

>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.)
I agree with you. However, I still am not sure on "waste basket" part. May be experts
would brighten and clarify this polemic. I don't have any experience on this issue.
 
>> >Admittedly, I did not yet read your UMP. (My blood pressure ;-))
>> See above.
>Be aware of my blood pressure ;-) At _your_ risk ;-)
I will send it separetely. 

>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.
Both are responsible for putting data accross from one point to other. L4 is on 
a virtual link on networks and L2 is on logical link on a physical medium. 
To me, it is very obvious even before a closer look.

>Is there something like "prove by lack of contradiction"?
I guess, not cause whole induction part is missing :))

Alper K. Demir