UDP vs. TCP distribution [was: Re: [e2e] Can feedback be generated...]

Simon Leinen simon at limmat.switch.ch
Wed Feb 28 13:31:57 PST 2001


>>>>> "gm" == George Michaelson <ggm at dstc.edu.au> writes:
> 98 pre-dates a bit of an explosion in live content. I'd be willing
> to stake beer there is more UDP now.  Dunno if it's going to be
> rilly significant but I'd be suprised if it wasn't measurable.

Not sure if it's the beer or the mythical "explosion of live content"
(.../UDP/non-adaptive traffic) that forces me to respond.

Here's the distribution from one of our transatlantic links in the
busy direction for the last couple days (assuming NetFlow summary data
is accurate and my Perl hack(*) is correct):

GRE              213346212  0.04 %
ICMP            1083751656  0.20 %
IGMP                  7264  0.00 %
IP               763601220  0.14 %
IPINIP             2589084  0.00 %
TCP           532400385076 95.81 %
UDP            21201575665  3.82 %

So the 95% figure for TCP still looks reasonable in 2001, at least for
that particular link (which aggregates traffic from all universities
in Switzerland - non-"academic" network users may or may not have
vastly different usage patterns).  When I look at other parts of my
network, the TCP part is even higher (97-98.2%), probably because
there's very little NNTP going over the pond.

> (at least for me, I almost never seem to negotiate TCP based
> transport for the live or semi-live content being sourced on
> networks I can measure which are admittedly very very edge networks)

If you're in Australia and the content is e.g. in the US, chances are
that limitations on the server and/or client side prevents negotiation
ofa TCP window size which allows the desired rate to be achieved given
the RTT constraint.

For example I've seen video clips encoded for ~1000 kbit/s offered
over TCP from a server with a maximum window size of 32 KBytes.
Assuming otherwise ideal network conditions, you can easily compute
the RTT radius in which it is possible to stream at the required rate
under these conditions (left as an exercise for the reader).

> 98 Also predates an explosion in IP-in-IP and other encapsulated
> flows (VPNs, IPSEC, PPPoE) so I'd be willing to hazard there are
> more fragmented flows than shown there.

It also predates the explosion of applications such as Napster and
Gnutella (which both run over TCP), whose traffic volume dwarfs that
of all UDP traffic (at least on our network).
-- 
Simon.
PS. are you going to IETF in London? (for the beer :-)

(*) Call this on the output of "show ip cache flow".

#!/usr/bin/perl -w
my %total; my $total = 0;
while (<>) {
    my ($proto,$nflows,$fps,$ppf,$bbp) = split;
    next unless defined $bbp && $proto =~ /^[A-Z]/ && $nflows =~ /^[0-9]+$/;
    $proto =~ s/-.*//;
    my $this = ((($nflows) * $ppf) * $bbp);
    $total{$proto} += $this, $total += $this unless $proto eq 'Total:';
}
foreach (sort keys %total) {
  printf ("%-12s %13.0f %5.2f %%\n", $_, $total{$_}, 100.0 * $total{$_} / $total);
}
1;



More information about the end2end-interest mailing list