On 10/28/08 13:32, Darren Reed wrote:
On 10/28/08 04:22, Kacheong Poon wrote:
Darren Reed wrote:
Correction: in theory this should only impact UDP traffic,
in practice it affects UDP *and* TCP traffic.
Why in theory fragmentation should only impact UDP
traffic? What is in the protocol spec which says
that there cannot be TCP fragments? In theory, it
can happen with any traffic...
In practice, I think most fragments in the Internet
are UDP traffic, such as streaming media data. At
least this is what the study I've read some years ago
indicates (*). For this kind of app, I believe it is
the response from server which is being fragmented.
And I guess to load balance this type of traffic, a
DSR set up is appropriate and the fragment issue does
not matter.
The above study is old and I don't know if there is
any recent one. But given that nowadays most, if
not all, client TCP stacks in use support PMTUd, I
suspect that TCP fragments should be even rarer than
the data in the above study shows. Do you have data
showing that the above is no longer true in today's
Internet?
There is the continued feedback from ipfilter users that
harass me when fragmentation things don't work. The
problem isn't that "most fragments on the internet are UDP",
it is the small percentage of TCP packets that are, which
when not handled correctly, cause lots of noise.
Darren
I think we are getting away from the question which is handling of
fragments critical for Phase 1 of ILB project. During identifying of
critical features for ILB Phase 1, this one was not raised as a "must
have" item.
So I would like to find out whether this is considered to be a must have
item for other protocols or not.
The simplest way to handle fragmentation may be to set up a load
balancing rule so that all fragments are to be handled by a specific
back-end server. But I am still not convinced if handling of fragments
is critical for Phase 1 of ILB project.
Can folks with experience with load balancers provide some input?
Sangeeta
_______________________________________________
networking-discuss mailing list
[email protected]
