[e2e] YNT: A Question on the TCP handoff

[Alper Kamil Demir]

>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.
I seems the format of my emails are getting worse,  the more I try. 
Befor I send emails they look nice; when I look them after posting,
they look terrible. I don't know what to do when using Microsoft OWA.
I am somehow stuck to use it cause there is almost always problems
with IMAP, POP in my university.

>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.
Yes, FH is the one end point of the warm-up connection and SA2 is
the other end. No, in warm-up connections, MHs are never end points
cause they are not in the cell of related SAs yet.

>I will try to understand..... (may be I suffer from very early
>Alzheimer-Symptoms.... %-))
It seems not so far %-))

>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?
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
updated on FH. The congestion statefrom FH to SA2 , resulting from "warm-up 
connection"  is ready to be handed over; only the last mile from SA2 to MH is
missing in the congestion state. However, some other mechanism could be used
to estimate and integrate with already known congestion state resulted from
"warm-up connection". 


> I referenced RFC793 in order to give the definition of "connection"; NOT "congestion"
>I did not mix up these two ;-)
Then, I didn't understand why you had asked me to define "connection". 
We can skip this, if you like.

>> 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 guess, we are on the same track now.

>> 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*
Unfortunatelly (may be likely ;), I wasn't around back then. However, I remember a related
thread in a couple of years back.

>> A start on the congestion control would be the V. Jacobson's SIGCOMM'88 paper and S. Floyd's
>Really? :-)
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.

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

>However, it should be part of any actual TCP connection. A TCP
>implementation which does not do congestion control should be considered
>broken.
I am, in a way, don't agree here with you. I don't understand why TCP should be responsible
for this. For a long time, and still, UDP is the privilidged child of the Internet from the point
of bandwith share. To me, congestion control is a type of "implicit admission control".
Admission Control is a QoS mechanism. TCP cares about network quality of service whereas UDP
doesn't. Moreover. Internet is "best-effort"; meaning only embodying of one type of service
based on "fate-sharing" principle. To me, Congestion Contro is not a transport layer issue.
It is a network layer issue. However, when integrated into transport layer it does prevent
network under-utilization. Hence to replace UDP, DCCP is emerged. There is UDP and DCCP, 
but there is no TCP without congestion control. TCP is actually TCP congestion Control
Protocol (TCCP), now. In a way, Internet has emerged with new congestion control protocols
to provide an "implicit quality of service" preventing congestion. The existence of RFC793 and 
other RFCs related to TCP and TCP congestion control is  evidence for this.

>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.
We are planning to use a mechanism to be used to take the last mile problem in 
our approach into account and integrate it into the FH-SA2 path.

>Please note: The last two lines were a pure blackbox understanding of a
>mobile network. It would be to detailed here to discuss
                                                 ^^^^^^^
;)) typo does happen. such as my "to" two" typo.  Does this prove
history is recurrence ;)) Especially, I have used some variety of keyboards.

> >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?
The whole path from FH to SA2 is new path. Only the last mile is missing. 
The true bandwidht interration of the last mile is not possible other than 
estimating it before MH moves into the area of last mile. 

> 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.
If I forget about e2e semantics then it seems there is no problem at all. It seems
I am digging no problem here. The only problem is if it is possible to replace/update
the sender's congestion state at all. 
I agree with the rest. However, we are trying to attck the problem from the "transport layer"
(congestion state changes) and not taking "lower layer interactions and effects"
 into account for now. 

> >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!
If it is not on the last mile, then in our approach there is  no problem.  However
if it is, then we are planning to use an estimation to take this into account. 

>Yes. So, there is a sending rate. It´s a consequence of proper ACK
>pacing :-)
I would say a rate consequence of proper "ack pacing" constrained with RTT.

>O.k. With which rate?
The rate of whatever the "warm-up" TCP connection from FH to SA2.

>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... ;-)
I guess I misunderstand and underestimate this last mile issue. 
Could you give a reference?


>Again: whith wich rate?
If you are asking for packet size, we could use some estimated packet size. The rest
is TCP slow start, etc from FH to SA2 for a short of time till congestion state is 
handed over.

>> Others are enhancements.Semantics is kept the same as it was.
>Oh yeah ;-) Frankly, I do not completely agree here :-)
Why?

>We have a big waste basket in the ground floor of our house where old
>paper is gathered.
May be, they are the entropy of the universe.

Alper K. Demir