[e2e] YNT: A Question on the TCP handoff

[Detlef Bosau]

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

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



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

Thank you.

However, when I apply for a job, I don´t know whether one expects a dead 
  body, some guy suffering from Alzheimer or some guy suffering from 
Creutzfeldt-Jacob-Disease when one reads "age: 42".

I´ve not written any CVs for some months now, I´ve simply given up :-(((
(Don´t ask me from which money I´m living, I don´t know.)

O.k., that´s off topic as well, I know. But sometimes, it helps to talk 
about it.


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

Welcome to the club :-) So, we´re already two guys, who do not 
understand your approach =8-)

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

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.

E.g.: CWND = 20 kbyte, then you might have 10 kbyte TCP data on the fly 
and ACK datagrams for 10 kbyte respectiveley.


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.

And exactly that´s your problem and I do not see an easy way to overcome 
it.

In addition, depending on your protocol, some data may still reside on 
SA1 after the handover and might be redirected to MHs new location.
So, for a short period of time, FH and SA1 might be competing for 
ressources.

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

I still do not really know, wheter we talk about the same thing here...

We´ll see.

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

Hey :-) You read my work? Fine :-)

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.


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

Hang on here.

I will not repeat the whole congestion control debate here because this 
is sufficiently summarized in the congavoid paper.

For me, there are basically two alternatives for congestion control.

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.

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.

Anyway, you´ll need some kind of congestion control in order to prevent 
congestion collapse.

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.

In the congavoid paper, VJ writes the Internet _has_ _seen_ several 
congestion collapse, they are not pure phantasy.


> It is a network layer issue. However, when integrated into transport layer it does prevent

If you place congestion control in L3, you advocate a mechanism as 
proposed by Keshav. Right?

> network under-utilization. Hence to replace UDP, DCCP is emerged. There is UDP and DCCP, 

First of all, it prevents network "over-utilization" :-)

Concerning DCCP: From a very first glance, DCCP is intended to be 
compatible with TCP congestion control.

> but there is no TCP without congestion control. TCP is actually TCP congestion Control

Yes.

TCP assumes a stream model and hence there is a possibility to do 
congestion control for TCP.

UDP does not.

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 addition, a sliding window protocol like TCP _REQUIRES_ an estimation 
of a faire share of capacity. It´s the purupose of congestion control to 
provide this estimation.

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

I basically don´t follow your mixup of congestion control and QoS.

QoS is commonly used for _guaranteed_ service. Congestion control 
provides for fairness.

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.

So, why don´t you simply use TCP?

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

Have fun :-)


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


I once was confronted with a french one.... God in Heaven :-)

> 
>>Excuse me?
>>Where is the difference here?
> 
> The whole path from FH to SA2 is new path. Only the last mile is missing. 

_Yes_.

> The true bandwidht interration of the last mile is not possible other than 
> estimating it before MH moves into the area of last mile. 
> 

This is obvious because you don´t know anything about the wireless 
channels quality in advance.

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.

> I am digging no problem here. The only problem is if it is possible to replace/update
> the sender's congestion state at all. 

And I´m in doubt here.



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

That´s obvious.

But how will you know this in advance?


> if it is, then we are planning to use an estimation to take this into account. 


Oh yes ;-)

I see, I have to work somewhat faster ;-) For the rest of the world: 
That´s an actual competition between Turkey and Germany =:-)


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

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


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.

Unfortunately, it´s hard to find good papers on that issue. Hence, I 
actually try to understand this issue myself.

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

See above.


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


In Germany, wastepaper is typically used to make toilet paper of it....

Detlef



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