[e2e] YNT: A Question on the TCP handoff

[Detlef Bosau]

Alper,

some remarks.


You wrote:

> 
> I mean rate depends very on RTT when depending on "ack pacing".
> 

>From the basic ideal the rate of a TCP flow is indpendent from the RTT. 
Pracitically, it may oscillate because traffic might be bursty and
irregular.

Perhaps, you think about the contents of my "very preliminary table",
which I don´t find even _that_ preliminary.
And perhaps you think about PTE and why I proposed it. (It´s not becaus
Santa Clause is comming in his Coca Cola advertisment suit ;-))

Then you wrote:

> To me, "congestion control" is a QoS mechanism.

I totally disagree here.

It´s exaclty the other way round. Of course, QoS architectures can
prevent congestion. 
However, "congestion control" does not provide any kind of QoS.

Congestion control shall prevent "network overload", i.e. congestion
callapse.
QoS architectures do scheduling, admission control etc., hence if this
is properly done congestion collapse must not happen.


And now for something completely different: Your approach.

Eventually I think I understand what you´re doing.

Your "warm up connection" shall occupy those "packet slots" from FH to
SA2 which are later being used by your TCP connection:
When your mobile enters the new cell, I think you simply drop the warm
up connection and update the state variables in your
"old" TCP connection which then is routed along the new path.

Now, the problem is that in sliding window you have

last_ack....(on the fly)....last_seq..(free space)....last_ack+CWND.

Ideally, in settled state each ACK which arrives at the sender clocks
out one TCP packet.
And each TCP packet which arrives at the receiver, clocks out one ACK
packet. (I intededly ignore delayed ACK here.)

Perhaps, you have seen the little "ball chain" which some people use as
a toy or perhaps you have seen this in physics at school.
That´s basically, how TCP works.

Now, when you reroute your flow, you don´t exactly know how much of your
CWND is currently occupied, you don´t know how
to set last_seq. Or your scoreboard or whatever.

You don´t know whether your achievable throughput has changed.

So you update a few of your state variables whereas you leave other ones
(last_seq, last_ack, scoreboard in TCP/Reno) completely
untouched. The relationship between these variables is ignored.

Simply spoken: I don´t buy it.

Your path changes and so do his properties. Consequently, TCP will
settle and adapt.

In addition: Which problem do you intend to solve? We talked about
mechanisms a lot. However, it´s not quite clear which problem
we solve in your approach.

Detlef


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