Re: 2.5g/3g comments

["Andrei Gurtov" <[e-mail]>]

Hi,

Sorry for delayed reply.

Mark's comments:

>   * I don't understand the sentence "For LFNs, it is necessary to
>     utilize the available network bandwidth."  Wouldn't the goal be
>     to utilize the available bandwidth in *any* network?

True, so let's say in "LFN utilizing the available bandwidth is of
particular concern"

> Section 2.2:
>
>   * I don't understand the bit that says TCP can tolerate the
>     asymmetry without need for congestion control.  That seems
>     busted to me.

It is. It should be "without need for ACK congestion control or ACK
filtering"

> Section 2.6:
>
>   * I do not understand the second paragraph at all.  Why does it
>     matter if the middle of the network changes to TCP?
>     Specifically, why would it matter that window scaling is only
>     negotiated at the beginning of a connection?  I am sure I am
>     missing something here, which likely means that you need to put
>     a little more explanation in this paragraph.

The idea I had here is that previously people were tuning TCP with some
particular network environment in mind. For example on slow gprs link it
makes sence to limit the receiver window to 10 KB to avoid overbuffering in
the network. This kind of optimizations are no good when TCP connections
jumps from one network to another that have completely different
characteristics. Maybe window scaling wasn't a good example since TCP
connection activated in 3g with scaling can most probably survive later in
2.5g. More research is required here, but I hope to communicate at least the
basic idea at this point. So if you agree with this line of thinking, I'll
try to rephrase the paragraph.

> Section 4.8:
>
>   * First sentence needs a reference.
>
>   * "one proposed in" --> "one specified in"
>
>   * I don't like the sentence about reference [44].  First, [44] is
>     old.  It may very well make that claim (which is likely from
>     another source, actually).  But, more recent expereince has
>     suggested that this is not true.  I suggest at least citing the
>     work Vern and I did (SIGCOMM 99) that suggests that *in general
>     networks* timing every RTT buys you little or nothing.  It seems
>     fine to me to recommend timing every segment in 2.5g/3g networks
>     if you think that will help and you have references to back up
>     that statement.  However, I think your statements are too broad
>     and should be tempered with some references to studies showing
>     the flip side of the argument.

To me arguments in [44] sound conviencing as it basically says that
according to the control theory too rare sampling of the signal leads to
aliasing. What about the following compromise?

"TCP connections with large windows may benefit from more frequent RTT
samples provided with timestamps by adapting quicker to changing network
conditions [44]. However, there is some empirical evidence that for TCPs
with RFC2899 timer [32] timestamps provide little or no benefits on backbone
Internet paths [xxx]."

[xxx] M. Allman and V. Paxson, On Estimating End-to-End Network Path
Properties, ACM SIGCOMM '99, September 1999, Cambridge, MA.

>   * I think [42] is being oversold.  My reading of the I-D says that
>     we should always get a bad RTO according to [42].  However, I
>     would guess that is not the claim of [42] -- and if it is, it is
>     wrong and I can find references that show it not to be the case
>     all the time.  I am guessing [42] does, indeed, show this
>     behavior for *some* setup.  So, the I-D should note that simple
>     NS2 simulations of specific situations can show bad RTOs with no
>     delay spike.  And, I would also add the note that this is not
>     general behavior when using an RFC 2988 compliant RTO.  (Andrei-
>     beat me up if I am way off here.)

Well, a tech report in no match to a sigcomm paper, so I think it's
appropriate to downgrade the language in this paragraph.  However,  it
already says that on 2.5g3g paths TCP *can* underestimate the RTT, spurious
timeouts *can* occur and timestamps *can* help. So do you want these to be
"mays"? We can also add a sentence: "The probability of spurious timeouts
depends on the RTO computation as well as the policy of restarting the
timer. In particular, a conservative timer such as given in [32] makes
spurious timeouts less likely." I could also refer to the delay spike draft,
but I guess the RFC editor wouldn't like that.

Andrei