Sorry to get back to basics, but I have not followed all the Flow
Label discussions or read all the drafts. I have read
draft-ietf-6man-flow-ecmp-00.txt
draft-ietf-6man-flow-update-01.txt
pretty carefully and I still don't quite understand what real problem
we are trying to solve -
The goal is not to split single flows across multiple links. In fact,
based on the experience that this causes excessive disordering, we
generally require that load splitting techniques must avoid splitting
flows across links.
Which gets us to the problem. In using multiple links (ECMP /
Hi Thomas:
I've seen different requirements depending on where the utilization
would be.
a) Close to the source of the source or destination, the flow label
could be used in an application-aware fashion, for instance to influence
the routing of the packet in VRFs. We'll note that we do not have
The goal is not to split single flows across multiple links.
Sorry, I know that. Was I that unclear? :-(
But isn't it then a goal (or rather a *requirement*) to split traffic
between a given src/dst pair across multiple links? I.e., there is
enough traffic between a given src/dest pair to
Hello, Thomas!
On 11.01.11 17:33, Thomas Narten nar...@us.ibm.com wrote:
That would seem to be what we are after. I'm trying to understand
exactly which operational scenarios would actually see benefit from
this, and get a sense of how common they are. Are we trying to solve a
common problem, or
Yes, the usage of ECMP / LAG is very common. Yes, there is plenty of
data that shows that using just the src and dst IP address in the hash
is NOT good enough. (This does start to get into the quesiton of
whether blindly using the ports is good enough,l but that is the current
practice.)
[LY] Statistical approach works well under the consumption that there
are
thousands of flows and they have the similar rates. Today's Internet may
have the flows that only have few packets and the flows that have
thousands
packets per second and last long. Hash does not work well
Lucy, Brian,
On Jan 11, 2011, at 08:41 MST, Yong Lucy wrote:
In fact no solution works well for short flows and the problem isn't
important
for long flows with few packets. So I think it's OK to discuss a solution
that works for long flows with many packets, since that covers most
of the
On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
It's probably better to say that a hash algorithm works well where
individual, long-lived flows (regardless of traffic type) are a small-ish
fraction of the physical BW of any individual component-link in a LAG or ECMP
group. It's when
Fred,
On Jan 11, 2011, at 10:29 MST, Fred Baker wrote:
On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
It's probably better to say that a hash algorithm works well where
individual, long-lived flows (regardless of traffic type) are a small-ish
fraction of the physical BW of any
Hi Thomas,
Token operator here ... :-) See below.
On Jan 11, 2011, at 06:41 MST, Thomas Narten wrote:
Sorry to get back to basics, but I have not followed all the Flow
Label discussions or read all the drafts. I have read
draft-ietf-6man-flow-ecmp-00.txt
On 2011-01-12 04:41, Yong Lucy wrote:
[LY] Statistical approach works well under the consumption that there
are
thousands of flows and they have the similar rates. Today's Internet may
have the flows that only have few packets and the flows that have
thousands
packets per second and last
On Jan 11, 2011, at 10:14 AM, Shane Amante wrote:
What causes pain and/or worry to us operators is when someone launches a
large *individual* macro-flow[1] at the network that start to represent a
decent fraction of the overall capacity of a physical component-link
underlying a LAG and/or
13 matches
Mail list logo
