[e2e] YNT: A Question on the TCP handoff

[Alper Kamil Demir]

>It´s off topic, but usually I recommend: Open your CDROM drive. Insert a
>Linux installation CD. Powercycle your computer. Follow the instructions
>on the screen :-)
If life will be much more easier, then why not. However, I don't see 
any operating system related issues here. I have both installed and
use either one according to my purpose, needs and convenience. 
I don't have any profit from any operating system. If I did, certainly,
I would choose the most profitable one.  I find this topic similar to being a
heavy fanatic of an X soccer team where one doesn't have any connection
with that team other that his own picking the team just for the personal ego,
etc... However, this is off topic.

>> This was my question in the whole thread. if this is ever possible or not without
>> corrupting e2e semantics of TCP. My approach is that only congestion state is
>Welcome to the club :-) So, we´re already two guys, who do not
>understand your approach =8-)
Oh, no. I understand our approach. Only, it seems like we are not looking at the same
picture. Pleease see my comments below.

>You lost me ....
>Let´s assume you do no splitting or spoofing and BS is simply a router.
>Then CWND on FH tells you hom many unacknowledged data, i.e. TCP packets
>on their way to MH and ACK packets on their way to FH, is allowed to be
>in transit. ACK packets must be counted for the bytes acknowledged in
>them, of course.
Forget about BS for now and assume that each SA is on BS and SAs are middlewares.
If we are talking about mobility, in general, above problems are inevtiable. TCP solves
this issues on its own end to end. It we are talking about mobility, routing is the main issue.
We assume that network layer solves this issue. Anyway, this is not related to our
discussion. 
TCP is responsible for ACKs. Of course, when MH moves there are some TCP packets
and ACKs are on the fly on the ex-path. However, this is inevtiable and TCP will handle
this lost TCP packets issue. There will be no ACK problem as long as TCP semantics are
not broken. 
 
>You do not know which portion of these are situated between FH and BS,
>i.e. SA1 before handowver, and which portion is situated between BS
>(SA1) and MH.
Do I have to know? If TCP data packets or ACKs are lost on the way, then TCP
wilö recover it. Okay. I see why we don't understand each other. I guess this was my
mistake. However, I tried to clarify this misunderstanding. May be, 
"Handover" is not the right terminology to be used. I used update/copy instead of
"handover". 
"actual connection" is never replaced by "warm-up connection". Congestion and some
other parameters are updated on "actual connection". These parameters are resulted
from "warm-up connection". "warm-up connection" is created to find new path's congestion
state from FH to MH in advance using SA2 as an agent cause MH is not in the cell of SA2 yet.
It is known that MH will move into the cell area of SA2 from UMP. As a result a "warm-up connecction"
is established between FH and SA2. When MH moves into the cell area of SA2 congestion
state parameters are updated so that "actual connection" gets its fair share on the new path.

>And exactly that´s your problem and I do not see an easy way to overcome
>it.
Do you think that updating congestion state parameters of a TCP connection is
not easy?

>In addition, depending on your protocol, some data may still reside on
>SA1 after the handover and might be redirected to MHs new location.
This is inevtiable. Any approach will face this. As far as I know this issue is
ignored cause TCP will eventually solve this. 

>So, for a short period of time, FH and SA1 might be competing for
>ressources.
SAs don't compete for resources. They try to find fair share of actual connections'
fair share on new paths. SAs create temporary "warm-up connection" for a short 
period of time. I don't understand how you concluded that SA1 would compete 
for resources. I think according to our reference model, you meant SA2.

>> I didn't mean for you cause I am familiar with you "Path Tail Emulation" work and it
>> is referenced there, too. I meant we are on the same track on this.
>Hey :-) You read my work? Fine :-)
Yes. I did. It is very well put.

>Perhaps you could even have a look at my humble try for the "lower
>layers"? At the moment I would appreciate some assistance / correction /
>  feedback in some channel coding issues I only begin to understand.
I had a look at it, too. It is very preliminary. I wouldn't say
"lower layers in mobile networks used for packet swithcing". I would
say ".... interacting with packet-switching" or some orher thing cause
packets are not switched on the lower layers. They are frames. I know 
I hear something you beg for the differ. I don't know. I guess it has been
used in the literature that way. Just an idea.

>For me, there are basically two alternatives for congestion control.
For any communication system, there is these two alternatives.
This is not new. At least, for a taxonomy from the systems point
of view.

>1.: Distributed: Each flow cares for itself, each flow is responsive (in
>the sense defined by e.g. Sally Floyd). Ideally, such a system will
>eventuyayll converge to a fair share of ressources between all flows.
>2.: Centralized: There is some mechanism / entity which assigns
>ressources to the individual flows and enforces the flows´ rates
>throughout the network. IIRC, this approach is conducted in Keshav´s PhD
>  thesis.
Somehow, I am truly unable to imagine a centralized approach for the Internet at all.

>A good discussion of this issue can be found in "Myths about Congestion
>Management in Hish-Speed Networks" by Raj Jain in the early 90s.
I am not saying that we don't need congestion control. This reminds me QoS support
versus overprovisioning.

>If you don´t agree with existing congestion mechanisms, you should
>propose a better one. Nevertheless, it´s commonly accepted that some
>kind of congestion control is inevitable.
I don't dare not to agree. I respect very much. 

>If you place congestion control in L3, you advocate a mechanism as
>proposed by Keshav. Right?
I am not familiar with Keshav's mechanism if you are not talking about "fair queuing" 
or "packet-pair", IIRC!!

>First of all, it prevents network "over-utilization" :-)
what is network "over-utilization"?

>And in contrast to your view, UDP leaves congestion management as well
>as reliability issues primarily to the applications. E.g. a rate control
>media stream using UDP is responsible for congestion control and
>responsiveness on its own.
In the past, UDP traffic was not very high. Recently, there have been increase in the
UDP traffic and need for congestion control as we already know. This was the
main reason why UDP didn't implement "congestion control". Some applications
tried to implement their own "congestion control". However, we already know
that to get it right is not that easy. 
I don't think that any application and protocol above network layer is responsible for
it in the Internet architecture. What prevents me from sending IP datagram on the
Internet? Standards? To me, if a protocol does not agree with standarts, it does not
work at all. As long as I use IP and anything on top of it, it works on the Internet. Right?
Who controls "congestion" on the Internet?  Protocols adopting congestion control 
on top op IP. If any protocol does not adopt and be a bad guy, who will punish the bad
guy and how? Moreover, how will I know the bad guy?

>I basically don´t follow your mixup of congestion control and QoS.
I don't think it is a mixup. To me, congestion control is adopted to some
transport layer protocols in order to prevent congestion hence increase service 
quality of IP packets. It is an implicit result. To me, "congestion control" is a
QoS mechanism.

>QoS is commonly used for _guaranteed_ service. Congestion control
>provides for fairness.
Are you saying that "best-effort" is not a QoS? Please, have a look at Diffserv and Intserv
service classes. May be not Diffserv yet. I see a mixup with "congestion control" and "fairness".
Congestion control does not necessearily have to be fair for every bit of the network. In TCP, it is 
cause there is no bit discrimination on the Internet, yet.

>Perhaps, you can invent a reliable UDP based protocol controled by DCCP.
>However, I think this would result in a TCP compatible protocol the
>behaviour and purpose of which is similar to that of TCP.
This is integration or differentiation choice. If you integrate you have the chance
of getting more efficient protocol definition. If you differentiate or layer, you get
basic building blocks. This is a very hard decision, I think. You might have
useless basic building blocks and less efficient protocols. On the other hand,
you might have things duplicated in different places.

>So, why don´t you simply use TCP?
I am whenever I need it :)

>Consequently (you´ll foresee my comment ;-)) you do not know in advance
>where the bottleneck is, particularly you don´t know whether packets
>will pile up and eventually are discarded at SA2 or at some intermediate
>node between FH and SA2.
As I explained above, "warm-up connection" will solve the bottleneck or congestion
state problem on the new path. Why do you think that there is a "warm-up connection"
between FH and SA2 for a short period of time before MH moves into the cell area of SA2?
 
>> If it is not on the last mile, then in our approach there is  no problem.  However
>That´s obvious.
>But how will you know this in advance?
Okay. I explain it again. "warm-up connection" will know it in advance.That's why we have
"warm-up connection".

>> if it is, then we are planning to use an estimation to take this into account.
> Oh yes ;-)
No any other solution can truly solve this problem. There is no choice other than
estimating it and taking it into account.

>I see, I have to work somewhat faster ;-) For the rest of the world:
>That´s an actual competition between Turkey and Germany =:-)
No, you don't need to ;)) Competition on what? Your comments and discussions
with you have been very useful, really. However, if you like to compete, let the
championship begin :))) Have there been any unreel competitions?
 
> I would say a rate consequence of proper "ack pacing" constrained with RTT.
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^?
I mean rate depends very on RTT when depending on "ack pacing".

>I will have a look whether I find it. It may take some time, I don´t
>have it in mind where the paper of Michael Meyer was published.
Thank you very much.

Alper K. Demir