[e2e] YNT: A Question on the TCP handoff

[Alper Kamil Demir]

>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.
Could you please check RFC3448 (TCP Friendly Rate Control (TFRC):
Protocol Specification. It does depend on RTT.

>> 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.
How dou you put the other way round? What is an "expected rate"
of TCP? isn't it a QoS specification? I think it is. Any traffic control is
a QoS mechanism. One can employ a QoS mechanism in order to utilize
the network resources and/or traffic differentiation.

>QoS architectures do scheduling, admission control etc., hence if this
>is properly done congestion collapse must not happen.
Not necessarily. Some traffic engineering, overprovisoning could
provide some sort of QoS. You might have a "best effort" or some
sort of default service class and still need to implement some sort of
congestion control mechanism so that traffic collapse must not happen.

>Eventually I think I understand what you´re doing.
I am very happy that, finally, you understand our approach.

>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.
That is exactly what we do. I am happy that we got each other.

>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.)
That's correct. I don't see any problem with last ACK sent by receiver (MH).
Eventually, it will be received by sender (FH) and will clock out one TCP packet.
The rest is upto routing to the packet to the receiver. Of course, oscillations
will occur due to mobility. This is inevitable.

>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.
This is due to routing and inevtiable. During that time. some sort of
oscillations will happen. However, I don't think that any other proposed
mechanisms have dealt with this routing issues. If so, any reference???

>You don´t know whether your achievable throughput has changed.
I know the achievable throughput got from "warm-up connection". 
Am I missing something?

>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.
That's correct. The rest would be enhancements for different TCP
variants.  Still, I am unable to see how last_seq, last_ack will be
effective to our approach. 

>Simply spoken: I don´t buy it.
Seems like we won't be able to sell it to you.

>Your path changes and so do his properties. Consequently, TCP will
>settle and adapt.
However, adaptation would be much more faster that any other mechanisms
due to adaptation parameters of "warm-up connection" and using this parameters
immediatelly so that TCP will settle and adapt to path change (won't go into
slow start due to time out, etc.).

>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.
The same problem tackeled in I-TCP, Freeze-TCP, M-TCP, Snoop, etc... We 
will compare them with our approach. However, I am unable to find their 
implementation on ns-2. I am working on this.

Alper K. Demir