[Tsvwg] feedback on "Review: Quick-Start for TCP and IP"

Bob -

>                   Review: Quick-Start for TCP and IP
>                 draft-briscoe-tsvwg-quickstart-rvw-00

Many thanks for the review of Quick-Start.

We have submitted a revised version of the Quick-Start draft as
draft-ietf-tsvwg-quickstart-02.txt, and Appendix E addresses some
of the issues that you raised in the first three chapters of your
review.

We incorporated most of the changes that you suggested in Chapters
4 and 5 of your review, with the details below.

Again, many thanks.

- Sally
http://www.icir.org/floyd/

>4.  Suggested improvements; taking the Quick-Start design choices as
>    given
>
>4.1.  No control-data association

...
>   So, the router cannot know when or whether data
>   has started to arrive as a result of an earlier request.  

With the Report of Approved Rate addition to QS, routers now know
when data has started to arrive.  If routers are keeping per-flow
Quick-Start state, then they can use this.

We did not standardize the timeout used by routers; routers might
learn over time what timeout values work best for them.

...
>   There remains a problem where the data is delayed more than the
>   request/response was delayed.  

This is possible in a scenario where queues have built up. 
However, in these scenarios, there has already been a failure
of Quick-Start.

...
>   The likelihood of these race conditions is perhaps the size of a
>   pimple on a pimple, given Quick-Start is intended for an under-
>   utilised environment in the first place.  

Yep.  So we are leaving it as it is.

>4.2.  Alternative rate reduced nonce

>   S.3.4: The scenario where receivers may be evil, fickle beasts,
>   whereas senders are _always_ trusted to act totally and utterly in
>   the interests of the commonweal seems very contrived.  Certainly some
>   senders might be trusted.  But Quick-Start requires absolutely _all_
>   senders that might use a Quick-Start network to be trusted.

We have added the Report of Approved Rate, to allow routers or receivers
to check against cheating senders, if they so desire. 

...
>   The newly proposed scheme in draft 01 means that a dishonest receiver
>   has a 25% chance of correctly guessing how to undo a reduction of one
>   step in the rate response.

Yep.

...
>   If the receiver guesses correctly just once, its gain is
>   assured for a large number of future packets.

Nope.  If the receiver quesses correctly just once, it doesn't get
any gain unless its data packets in fact aren't dropped in the network.

...
>   If the receiver happens to guess right first time (1:4 chance), it
>   will get 2x initial download speed.  It becomes more difficult to
>   guess how to undo two or more rate reductions: the chance to get
>   2^{r}x the rate is 1:2^{2r}.  But there is insufficient incentive to
>   prevent receivers having a go sometimes, particularly if theird
>   identity is hidden (e.g. behind a large NAT), so the sender cannot
>   record the receiver's reputation against its address, in case they
>   encounter each other again later.

One dis-incentive is that it is not necessarily in the interests
of the receiver to cheat.  If the cheating receiver is hidden behind
a NAT, there is not much that the sender could do, except for not
to use Quick-Start to that NAT.  If it desired, the NAT could use
the Report of Approved Rate to help detect cheating receivers behind
the NAT.

>   A possible alternative QS nonce would work as follows.  

Thanks, a very good suggestion.  I added it as an alternate
possibility in the Appendix on ""An Alternate Proposal for the
QuickStart Nonce".  We didn't adopt it because it is not clear
that such a powerful nonce is really necessary.

...
>4.3.  Maximum rate request
>
>   S.3.1: The max rate request of 1.3Gbps is inadequate for future-
>   proofing.  I know of projects already considering designs for burst-
>   mode allocation of the capacity of optical access networks to single
>   applications at higher rates than this.

My own belief is that flows that require more than 1.3Gbps should
not use Quick-Start, but should use some alternate mechanism (to
be developed at some point by some one else) that uses per-flow
state in routers.

>   The Quick-Start protocol seems to go to great lengths to minimise the
>   size of the IP Option field required, to the extent that the rate
>   request granularity has to be coarse (making a guess by a dishonest
>   receiver more likely to be correct--last para S.9.4.2).  Given the
>   smallest rate Quick-Start can request is 80kbps, worrying about
>   keeping to a 32bit header seems a little obsessive and unnecessarily
>   limiting [since writing this, draft 01 has changed to a 64-bit
>   header, but the Rate Request field is still 4 bits].

I actually don't see any need for a more fine-grained rate request.

...
>4.4.  Alternate rate encoding

Thanks, it is a good proposal, and I added it to the appendix as
an alternate rate encoding.  I didn't use it to replace the current
proposal, however, because I have a strong belief that flows starting
up at more than 1 Gbps should be using something more powerful that
Quick-Start.  I also don't agree that the powers-of-two coding in
the current scheme is not too coarse.  But perhaps we will learn
more from an Experimental deployment.

>4.5.  Request refusal behaviour

...
>   S.3.3, 2nd para: When a router wishes to deny a Quick-Start Request
>   the QS I-D allows it to zero the Rate Request, QS TTL and QS nonce,
>   rather than removing the Option altogether, which may be less
>   efficient.  Instead, it would be more liberal to say the router
>   should zero the Rate Request, and should set both the QS TTL and QS
>   nonce to random values, which may be implemented by clearing the
>   fields to zero for efficiency.  This is because the value zero for
>   the QS TTL or the QS nonce is not a magic value that the sender tests
>   for, so there is no need to use it.

DONE.

>   Alternatively, error codes could be placed in these secondary fields
>   giving the reason for denying the request.  Perhaps these codes could
>   be used to indicate to the sender whether it is attached to a network
>   that doesn't support QS at all (Section 3.8) as opposed to a
>   temporary refusal.

I like the idea of error codes, so I said that now the router should
zero the QS TTL and QS Nonce fields, but that later these fields
might be used for error codes.

...
>5.  Clarity and nits
>
>5.1.  For clarity
>
>5.1.1.  Qualify "incrementally deployable"

I clarified this.

>5.1.2.  Additional rate semantics unclear

I modified the draft to clarify the semantics.

Appendix D (since draft-ietf-tsvwg-quickstart-01.txt) lists a Report
of Current Sending Rate as one possible use for the Quick-Start
option, but we did not add it to the specification.

>5.1.3.  Other improvements for clarity
>
>   o  (Picky) The first bullet of S.3.3 says a router approving a Quick-
>      Start Request must decrement the QS TTL by one.  It would be safer
>      to say it should decrement the QS TTL by the same value that it
>      decrements the IP TTL, which may not always be 1 even though
>      RFC1812 currently says it should be (e.g. the now deprecated TTL
>      scoping used on the MBone had a different TTL decrement at
>      different types of border gateway--this is not to say that Quick-
>      Start should work with multicast, just that there may be other
>      operational practices that decrement the TTL by more than 1).

DONE

>   o  S.3.4 "The QS Nonce", first sentence:
>      "The QS Nonce gives the Quick-Start sender some protection against
>       receivers lying about the value of the received Rate Request...." 

>      "The QS Nonce allows the Quick-Start sender to give the network
>      some protection against receivers lying about the value of the
>      received Rate Request..."

I LEFT IT AS IS.

>   o  Fig 5: It would make more sense to call the Rate Request field in
>      the TCP Option the Rate Response field.

NO CHANGE

>   o  S.9.1: A more complete calculation of the benefit of Quick-Start
>      would help here (also necessary for the API in S.10.1).  That is,
>      in order to weigh the extra complexity against the benefit, we
>      need a formula for the benefit relative to TCP flows that would
>      last longer than slow-start as well as those that would finish
>      within slow-start.

We didn't do this.

>   o  S.9.4.4: "Misbehaving Middleboxes and the IP TTL" should surely
>      not be within S.9.4 "Protection against Misbehaving Nodes" as it
>      is a feature interaction (albeit due to irritating attempts by
>      middleboxes to `improve' packets), not a malicious attack.

DONE.

>   o  Why is S.9.5 "Attacks on Quick-Start" not a sub-section of S.9.4
>      "Protection against Misbehaving Nodes"?  My suspicion is that this
>      structure is due to an assumption that Quick-Start is somehow
>      secure as long as Quick-Start senders are trusted, even if other
>      senders on the same network aren't trusted (see Section 3.3).

DONE.

>   o  Other related work includes the class of approaches where an
>      initial request is sent into a `scavenger' class (Singh _et
>      al_ [lowTCP] give a useful set of references).  Also Adams _et
>      al_ [ARI05].

I ADDED [lowTCP].

>   o  S.A.7: "The Earlier QuickStart Nonce".  This appendix might
>      consider other related work that could have provided an
>      alternative nonce mechanism, in order to give rationale for why
>      they haven't been chosen.  The closest example I can think of is
>      Yang _et al_'s capability validation approach [DoScapab] and its
>      references (Perrig etc.).

We didn't do this.

>   o  (Picky) S.10.1: "Implementation issues...": As well as an
>      additional timer, Quick-Start requires the source to hold the
>      additional state of the TTL-Diff and QS nonce.

DONE.

>   o  S.A1.1: "ICMP" The ICMP message would need the source and
>      destination port numbers to know where to demultiplex to at each
>      host.

ADDED.

>   o  Both S.A1.1 "ICMP" and S.A1.2 "RSVP" talk of a corresponding
>      transport level to be used for the response.  But these requests
>      at the network layer don't imply any particular transport protocol
>      -- unless it is encapsulated inside the ICMP or RSVP header.

DONE.

>   o  S.A.6. "...requires less input to routers than XCP..." [explain
>      what this means?]

DONE.

>5.2.  Nits

Many thanks.  I have corrected all of the nits.

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg