Subject: Re: [Tsvwg] Re: draft-ietf-tsvwg-quickstart-00: A new contruction of RR Nonce

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 04 Oct 2005 09:56:23 +0100

Thanks for writing this up - and IMHO, it make sense to consider this as an 
attractive alternative to more complex varients.

I have no "feel" for the issues in using an 8 v. 4 byte nonce. Many of the 
issues in using an option field apply in both cases: space, PMTUD, etc; are 
there any specific impacts if we used 8 bytes?

Regarding the proposal of "Use Format X for the Rate Request Field"
- could this also have implications on this new-style nonce: Does allowing a 
range of rate formats, imply a range of nonce behaviours, if so - then I'm 
less happy with this as a "final" solution - because I'd still like to be 
fairly cautious on what I expect routers to do and I'd like to see some of 
this reach low-level support in standard routers.

Gorry

Sally Floyd wrote:

> Guohan 
> 
> 
>>This email proposes a new way construct the RR Nonce which provides a 
>>different kind of protection as the current one. 
> 
> 
> Many thanks for the feedback.  We have been thinking about alternatives
> for the nonce over the last few weeks with Gorry Fairhurst, who
> volunteered at the last IETF to give us feedback, and your email
> has encouraged me to rethink my preference for keeping the QS option
> at four bytes instead of eight.  I now think that an eight-byte QS
> option would be fine, with simplicity of the option valued over
> space-efficiency.
> 
> So here is the current version of the QS nonce that some of us
> are thinking about, based in part on your email, and in part
> on earlier suggestions from Gorry.  Your feedback would be
> welcome.
> 
> One open issue is whether there is any reason to strongly prefer a
> four-byte IP option over an eight-byte IP option.  If anyone has
> any feedback on this, that would be appreciated as well.
> 
> Many thanks!
> 
> - Sally
> http://www.icir.org/tmrg/
> --------------------------------------------------------------------
> The modified Lu proposal (also proposed by Gorry):
> 
>               0              1              2              3
>        +--------------+--------------+--------------+--------------+
>        | Option       | Length=4     |  QS TTL      |Resv. |Rate   |
>        |              |              |              |      |Request|
>        +--------------+--------------+--------------+--------------+
>        |  |                       QS Nonce                         |
>        |  |                                                        |
>        +--------------+--------------+--------------+--------------+
> 
>        QS Nonce:
>          Bits 0-1:  Reserved
>          Bits 2-3:  rate 15 -> rate 14
>          Bits 4-5:  rate 14 -> rate 13
>          Bits 6-7:  rate 13 -> rate 12
>          Bits 8-9:  rate 12 -> rate 11
>          Bits 10-11:  rate 11 -> rate 10
>          Bits 12-13:  rate 10 -> rate 9
>          Bits 14-15:  rate 9 -> rate 8 
>          Bits 16-17:  rate 8 -> rate 7
>          Bits 18-19:  rate 7 -> rate 6
>          Bits 20-21:  rate 6 -> rate 5
>          Bits 22-23:  rate 5 -> rate 4
>          Bits 24-25:  rate 4 -> rate 3
>          Bits 26-27:  rate 3 -> rate 2
>          Bits 28-29:  rate 2 -> rate 1
>          Bits 30-31:  rate 1 -> rate 0
> 
> The sender initializes the 29-bit nonce to a random value.  If the
> router reduces the rate request from rate K to rate K-1, then the
> router sets the two bits in the nonce for "rate K -> rate K-1" to
> a new random value.  (Almost any form of pseudo-randomness would
> do - it doesn't need to be fancy.) So if the receiver reduces the
> rate request by N steps, the receiver rewrites 2N bits in the nonce.
> The receiver reports the nonce back to the sender.
> 
> The receiver has a 1/4 chance of cleating about each step change
> in the rate request.  If the rate request was reduced by two or
> more steps in the network, the receiver has at most a 1/16 chance
> of reporting that the original request was approved.
> 
> The protection is the same whether one router makes all of the
> decrements in the rate request, or whether they are made at
> different routers along the path.
> 
> The reason for routers to enter new bits in the nonce rather than
> setting those bits to zero is to make it harder for the
> receiver to know the original rate request.  If the receiver
> doesn't know if the rate request was reduced in the network
> or not, then it is harder for the receiver to cheat.
> 
> There are six bits left as Reserved.  
> E.g., for new forms of rate request in the future.
> 
> The only issue would be whether there is some reason to strongly
> prefer a four-byte IP option over an eight-byte IP option.
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Sally Floyd <[email-masked]>
Date: Tue, 04 Oct 2005 11:26:36 -0700

>attractive alternative to more complex varients.

Good.  My inclination is to incorporate it into the proposal to be
considered for Experimental, unless I hear any negative feedback.

>there any specific impacts if we used 8 bytes?

I don't know of any reasons to prefer a four-byte instead of an eight-byte 
IP option, expect for the generic one of not wasting bandwidth
unnecessarily on headers in general.

>this reach low-level support in standard routers.

That wasn't a proposal.  That was just a list of some of the things
that have been mentioned at one time or another as possible uses
for extra bits in the Quick-Start Option.  It wouldn't have
implications for the new-style nonce - the new-style nonce would
work the same with any four-bit rate request field, regardless of
the format for interpreting the requests in that field.

I also don't expect there to be a need for other formats for the
rate request field.  The only reason I could think of would be if
the maximum rate request of 1 Gbps wasn't big enough.  But my hope
would be that people playing around with larger initial sending
rates than 1 Gbps are using something more powerful than Quick-Start
- e.g., some form of QoS, or of per-flow state at routers, or
end-to-end light paths, or something else...

- Sally