Subject: 2.5g/3g comments

From: Mark Allman <[email-masked]>
Date: Fri, 15 Mar 2002 23:54:40 -0500

Folks-

I have several comments on the TCP over 2.5g/3g I-D -- some
small-ish, some more dignificant.

I am happy to clarify or iterate (via email or in Minneapolis) if
that is useful!

allman

--
Section 1:

  * "technology of both" --> "technology for both"

Section 2.1:

  * "large enough window." --> "large enough window of outstanding
    data."

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

  * "worsening" --> "reduced"

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.

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.

Section 2.7:

  * Lots of stuff about the RTO I don't like in this document.  You
    say that the RTO is to closely follow the RTT.  I am not sure
    I agree that this was a specific design goal.  I think the RTO's
    job is to determine when a segment should be retransmitted (in
    the absence of an ACK).  Sure, we use the RTT as the basis.
    But, we also figure in the jitter.  And, in most networks the
    RTO is way conservative beyond this -- i.e., it does not try to
    track the RTT all that closely.

  * "increasing frequency" --> "increasing the frequency"

  * You note that the RFC 2988 based RTO estimator *reduces*
    spurious retransmits.  What are you comparing it to?  (I.e.,
    there is not another standard RTO.)

  * You note that increasing the RTT sampling can reduce spurious
    timeouts in BO systems.  You should cite something here or
    remove the statement.

  * You note that increasing cwnd is one way to avoid spurious
    RTOs.  I don't understand this.  When do we increas cwnd.  This
    needs described better (and, a reference given, if possible).

Section 3:

  * I chatted with Aaron about this today and he motivated this
    section for me as a bunch of information for those not terribly
    familiar with 2.5g and 3g technologies.  So, this section seems
    fine as an educational tool to me.  But, I think the intro
    should motivate that a little more.  

Section 4:

  * In the intro you note that all recommendations are in general
    purpose stacks and all are "safe".  I'd go at it a little
    differently.  I'd say that they are all IETF standards track
    mechanisms that the community has judged to be safe.

Section 4.1:

  * "The traditional TCP" --> "The TCP"

Section 4.2:

  * I'm sending a comment in a seperate email in hopes of catching
    Allison's attention.

Section 4.3:

  * "4.2, TCP round trip" --> "4.2, TCP retransmission"

  * I think the claim that LT is useful when sending small amounts
    of data might need hedged a little.  If we run out of data to
    send we can send via LT (because LT calls for the sending of
    previously unsent data).

Section 4.6:

  * "TCP may use" --> "TCP should use"

  * "[39] semantics." --> "[39]."

Section 4.7:

  * I'd note in the section title that you also need help from the
    routers in the network.

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.

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

---

From: "Andrei Gurtov" <[email-masked]>
Date: Thu, 21 Mar 2002 17:21:56 +0200

Hi,

Sorry for delayed reply.

>     to utilize the available bandwidth in *any* network?

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

>     asymmetry without need for congestion control.  That seems

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

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

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

>     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