-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Thomas Narten
Sent: Tuesday, April 05, 2011 8:08 PM
To: james woodyatt
Cc: 6MAN Working Group
Subject: Re: Pseudorandom Flow Labels
>What is *required* is that the hash function (or whatever functi
Snipped from RFC 4193 is this text. "pseudo-randomly allocated global
ID". If pseudo-random was accepted in this RFC, why are we discussing
pseudo-random again? One reason is acceptable to me that over the years
we learn to be more precise or more audience read the documents and thus
more folks
On Apr 5, 2011, at 17:08 , Thomas Narten wrote:
>
> What is *required* is that the hash function (or whatever function
> that is used) on the router maps the tuples in a *uniform* way across
> the range of possible outputs.
Then it seems like "Equidistributed Sequence" is the precise term you wan
Thomas Narten wrote:
>
> What is *required* is that the hash function (or whatever function
> that is used) on the router maps the tuples in a *uniform* way across
> the range of possible outputs.
>
> If you have 10 links, and all your Flow Labels are clustered around
> low ten values, but in an
> Discrepancy is a measure of the deviation of a point set from a
> uniform distribution.
Actually, the core issue is that we do not need the Flow Label to be
uniformly distributed.
In an ideal world, that would be a nice property to have. And all
things equal, better to have that propert than n
On Apr 5, 2011, at 14:48 , Thomas Narten wrote:
> [I wrote:]
>>
>> I share your concern. Would replacing "pseudo-random" with "low
>> discrepancy" address your concerns?
>
> Replacing the term with another would be fine. That said, the real issue is
> we need to define what we mean by whatever
> I share your concern. Would replacing "pseudo-random" with "low
> discrepancy" address your concerns?
Replacing the term with another would be fine. That said, the real
issue is we need to define what we mean by whatever term we use.
Thomas
On Apr 5, 2011, at 13:36 , Thomas Narten wrote:
>
> Case in point about how we are being *extremely* loose in using the term
> "pseudo random".
I share your concern. Would replacing "pseudo-random" with "low discrepancy"
address your concerns?
--
james woodyatt
member of technical staff, co
Thomas,
On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote:
[--snip--]
> I take it as a given that doing ECMP on the src/dst address gets you
> 80% of what you need today. Adding in the Flow Label (if set) will
> take you much further. I am not convinced you need real "pseudo
> randomness" in the F
Case in point about how we are being *extremely* loose in using the
term "pseudo random".
If you look at draft-gont-6man-flowlabel-security-01, it proposes two
different algorithms for generating Flow Label values.
Unless I'm missing something, neither of them actually provides
"pseudo randomness
At the core, my concern with "pseudo random" is that I (as an
implementor) do not know what I have to do do satisfy that requirement
and I think in some cases that cost is higher than justified by the
benefit. The current documents do not provide enough concrete
guidance, IMO. If we want folk to ac
Thomas,
With respect to your comments on, both at the mic at the 6MAN WG and on the
list:
draft-ietf-6man-flow-3697bis-02
draft-ietf-6man-flow-ecmp-01
draft-ietf-6man-flow-update-04
You seem to take issue with a recommendation for creating/selecting a
flow-label that is "pseudo-random". Can yo
Here are my comments on this document.
My main issue is that it continues to assert that flow labels are
required to be pseudo random. I am not convinced that is necessary and
I think it makes things more complex than necessary.
Detailed comments:
Review of -04
Also, it could be used as
Looking at the revised document, here are some additional comments.
One lightweight approach to ECMP or LAG is this: if there are N
equally good paths to choose from, then form a modulo(N) hash
[RFC2991] from a consistent set of fields in each packet header
that are certain to have the
Here are my detailed comments on the document. I did chat with Brian
directly in Prague about these points as well. Overall, I support this
document. But I think the wording in places needs another round of
revision.
A flow is a sequence of packets sent from a particular source to a
particul
15 matches
Mail list logo
