[e2e] YNT: A Question on the TCP handoff

[Detlef Bosau]

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

I cannot really imagine that the authors went wrong here, so it may be a
misunderstanding here.

I said:

          From the basic ideal the rate of a TCP flow is indpendent from
the RTT.

Let´s draw a reference network:

A-----------------------B  (Ethernet, 50 Meter)

And now lets keep the rate and shorten RTT:

A-----------B  (Ethernet, 25 Meter)

And now we build a really big RTT

A--------------------------------------....---------------------B 
(Ethnernet, fibre, 1000 Meter)

At least in this example, RTT and rate are independent.

May be that you ignore the concrete case but consider the "more general
scenario"....


The RTT depends on the path length / capacity, which is independent of
the throughput.

O.k., I see, the congestion sawtooth increases more slowly as the RTT
increases.

However, this is not my basic thought. The basic thought is that it it´s
tough to build a really convincing RTT/CWND
relationship. I did not think about this in detail and I know that there
are many attembts being made to do so.
However, to me it appears difficult to do it exactly.




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

No.

"Expectation" is a term of statistics.

And a pure description.

Nothing more, nothing less.


> a QoS mechanism. One can employ a QoS mechanism in order to utilize
> the network resources and/or traffic differentiation.

Exaclty. One can.

QoS mechanisms can used to control / prevent congestion.

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

The list given was neither complete nor compulsary.

> provide some sort of QoS. You might have a "best effort" or some

We talk about the Interent, right?

May be that you can do overprosioning to your convenience in a small LAN
or some hostel.

In the Internet, bottlenecks happen to occur.


> sort of default service class and still need to implement some sort of
> congestion control mechanism so that traffic collapse must not happen.

Again. This the typical VoIP justification in minor companies and
offices. It works in this context.
But I don´t believe in overprovisioning about the Interent.

In addition, congestion control by overprovisioning means to make router
queues that big that they connot
be exhausted by existing flows.

I think, the disadvantages of oversized router queues are pretty well
known.

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

In my consideration, last_ack is a state variable.

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

Even if MH does not movie, oscillation will occur

1. of course for the usual congestion sawtooth.
2. as a result from delay variation due to noise.

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

With which routing issue? 

Perhaps, your solution is clear to me. Now we have to find the matching
problem %-)


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

Yes.

And is this achievable by the wireless path as well?

That´s why I asked were your bottleneck is ;-)

Or your argument is: If the wired path is the bottleneck, we can´t help
it.
If the wired path is, the first what happens is a severe congestion - 

- if, yes if you somehow obtain the ACK packets which clock out your TCP
packets.

Otherwise your warm up connection would be of no use.

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

:-)

Basically, I think you have two or three target groups:
1.: If you pursue a PhD: Your supervisor. (Most important.)
2.: The community. (Also important.)
3.: Me :-) (not so important and perhaps too stupid to understand your
approach :-))

(I think, the "Theroy of multiple target groups" is known 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.).

Adaptation? 

What is adapted to what here?

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

What are your criteria?

Do you yout intend to build a new TCP flavor for "good look"? Or is
there are 
certain prolem you want to solve?

In addition: I´m not quite sure whether all mentioned approaches really
tackle the same problem.

> implementation on ns-2. I am working on this.

Fine!

So, you have the first step on your schedule: Add dynamic flow control
to the NS-2 implementation of TCP,
otherwise I-TCP, Freeze-TCP and M-TCP will not work as intended...

Have fun!

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