From: Philippe Verdy (firstname.lastname@example.org)
Date: Sat Mar 20 2004 - 20:55:15 EST
If you want proofs, look at the LOTS of routers and switches that perform
routing at the application level 3 (above IP), meaning that they maintain
session state for TCP and some wellknown protocols in order to adapt the MTU and
TCP window size dynamically between the various routing path.
It's quite common even if there's no firewall and no protocol filters, such as
in "smart switches". Today any good switch you would buy even for your home or
office would include this feature, which also allows better negociation and load
balancing of the bandwidth across distinct Ethernet paths with distinct work
loads and speeds. Any ISP will need such a switch in its network to distribute
the traffic from lower band links of its customers to a internal main loop or a
As load balancing is most often mandatory for an ISP to use a GIX and even in
many cases to use its expensive but fast peerings, an ISP will need such smart
switch that can compensate for bandwidth delays and limit the loss of datagrams
by aggregating datagrams with a Nagle algorithm, notably for TCP which represent
the bulk of its traffic.
Also this is needed simply to be able to maintain good QoS guarantees for some
types of traffic that need faster throughput even if it can be less reliable. A
critical traffic for example is the IGMP and BGP4 traffic, immediately followed
by traffic from its own DNS caches, and then the traffic for paid contents
(video on demand, legal paid music jukeboxes) or security...
Prioritization of traffic is needed simply to avoid the escalation of a major
failure due to infrastructure data becoming completely unavailable in case of
spike of traffic. When such spike occurs, this would cost too much for the
performance of low-priority TCP applications, as they would loose packets that
would need to be retransmitted after a reduction of the TCP window.
By using dynamic adjustments of the MTU and with help of the Nagle algorithm, a
TCP-aware router or switch can easily fragment and defragment TCP datagrams
without using IP fragmentation (whose cose is too expensive). TCP is smart
enough that the MTU can be legally be adjusted and data buffered in any
intermediate node, adding possibly a small delay before transmission, but much
less than if this packet was sent immediately into a too busy link, and that
acket was lost after timeout and had to be retransmitted.
----- Original Message -----
From: "Stas Khirman" <email@example.com>
To: <firstname.lastname@example.org>; <email@example.com>
Sent: Saturday, March 20, 2004 6:33 PM
Subject: Re: [the_gdf] Re: GWebCaches versus Pong Caches and Connections
> With all due respect, I do not think that any today's router is enough
> "smart" to reassemble TCP stream and fragment it anew. It maybe done by
> transparent application proxy, but I'll be surprised to see deployed by
> broadband ISP (due cost/performance ratio). In any case, you can avoid
> Nagle algorithm by requesting "real-time" bahaviour for your packets (
> in TOS byte) .
This archive was generated by hypermail 2.1.5 : Sat Mar 20 2004 - 21:30:10 EST