[e2e] YNT: A Question on the TCP handoff

[Detlef Bosau]

Alper Kamil Demir wrote:
> 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 ;)

It´s perhaps a similar reason while it´s difficult to forbid some mail
readers to execute attachments with the "sober" virus.

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

One problem in automatic line wrapping at the reader side are "ASCII
arts".
E.g. our network drawings :-)

I have difficulties with this issues myself.

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


The one endpoint of the warm connection is FH, correct? And the other is
SA2. It cannot be MH, because MH is not yet in the cell of SA2.


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

Hm. 

I will try to understand..... (may be I suffer from very early
Alzheimer-Symptoms.... %-))

What I do not understand is how the handover takes place and how MH is
made the endpoint
of a connection wich was terminated on SA2?


> I referenced RFC793 in order to give the definition of "connection"; NOT "congestion"

I did not mix up these two ;-)

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

And exactly that´s what I do not understand.

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

But you surely did not read the list before 1982 ;-) *SCNR*


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

Really? :-)

It´s a little bit combersome to find this using Google. It´s too much to
type (JC would certainly write: to painful to his hands :-))

Simply type "congavoid" and follow the first hit.


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

This is my opinion as well. However, I would be careful there as I´m not
too familiar with rate based and equation based
congestion control. To my knowledge Sally has authored and co-authored
quite a few papers on this matter.
In addition, there is quite some work from the more control-theoretical
community (Mascolo, Massoulie, Vinnicombe, just to name a few.)

But I believe I remember (however, I don´t know where I read it) that
Sally has called the congestion principle from the congavoid paper
the most important basis for congestion control in one of here papers.


> 
> >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?)

CWND is not in RFC 793.

However, it should be part of any actual TCP connection. A TCP
implementation which does not do congestion control should be considered
broken.

So, back to my point: It not only wouldn´t make sense, it´s
substantially wrong to consider TCP without the state variables CWND and
SSTRHESH.

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


Oh yeah! It does matter!

Particularly in mobile networks. We´re not talking about a "base
station" for WLAN. At least, I don´t.
Because in that case, shut your eyes, slip into silent slumber, sail on
a silver mist.... and talk to yourself: "It´s Ethernet".
Believe me, if it´s properly installed, you would not notice the
difference.


However, in mobile networks like GPRS with latencies up to several
hundred seconds and asserted latency bandwidth products in 
Megabyte magnitude (I think, Michael Meyer, Ericsson, has written
something about that) the last mile _does_ matter.

Please note: The last two lines were a pure blackbox understanding of a
mobile network. It would be to detailed here to discuss
these details, but in fact I think some of these issues need a very
careful discussion, perhaps even some redesign in some details.
(At the moment, I try to think about it a little bit in public, have a
look at http://www.detlef-bosau.de/layers.html if you are interested.
It´s early work in progress. But I´m in the need of comments.)



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

Excuse me?

Where is the difference here?


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

Forget about the TCP end-to-end semantics for the moment. First of all,
they could be maintained even in the presence
of PEP etc. Second, we must not simplify the wireless part too much. The
wireless part not only consists of some
electromagnetic waves between two antennas. At least, there is typically
a Radio Link Protocol between BS and MH.

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

Yes. So, there is a sending rate. It´s a consequence of proper ACK
pacing :-)

I´m a "window guy". So, when I talk about "rate control", I always mean
ACK pacing :-)

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

O.k. With which rate?

For the relationship of rate, bottleneck and windows please refer to the
congavoid paper,
page 3, Figure 1: Windw Fow Control ´Self Clocking".

I think, if youre dealing with TCP, you will have this figure in mind
anyway.
(I´m always amused when researches claim numerous inventors for packet
pair and packet train techinques.
 It´s invented _here_ in this very figure. Any later inventions are only
the moments, when people begin
 to understand the congavoid paper :-))


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

Hm. When we face a LBP of 20 Mbytes (which I read in a paper by Michael
Meyer) on the last mile
and start from a CWND of 32 kBytes in a warm up connection, it might
take some time to adapt... ;-)

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

It will not really "harm" as it is intendend to share the available
capacity between the flows.
But we must not ignore it. Particularly as it requires the same
bandwidth as the real flow.

> 
> >Will it throttle
> >competing flows although it does not actually convey any data?
> Yes, it will but it will convey dummy data.

Again: whith wich rate?

The _rate_ comes from the self-clocking and immediately follows from the
bottleneck rate as can bee seen in the aforementioned figure.
(It´s one of the most important figures I´ve have seen in networking.
However, it´s quoted in numerous textbooks and _not_
carefully explained.)

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

Oh yeah ;-) Frankly, I do not completely agree here :-)

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

No. Frankly. If Van couldn´t, I could neither....
.
> >> 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

Thank you!

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

We have a big waste basket in the ground floor of our house where old
paper is gathered.

Detlef


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