[IP] FCC Commissioner: "Engineers solve engineering problems"

[David Farber <dave@farber.net>]

________________________________________
From: Richard Bennett [richard@bennett.com]
Sent: Monday, July 28, 2008 8:07 PM
To: David Farber
Subject: Re: [IP] FCC Commissioner: "Engineers solve engineering problems"

There is a sense in which the Commissioner is right about Jacobson's
Algorithm, Mike: it puts the onus for congestion management on TCP, in
the sense that it requires TCP end points to back off, while it doesn't
put any such requirement on UDP streams. Given that most real-time
traffic uses UDP, Jacobson makes TCP tussle over the bandwidth that's
left over after UDP has its fill.  A number of witnesses pointed this
out to the Commission in the course of its en banc hearings on traffic
management. That's not to say that UDP enjoys absolute priority over
TCP, just that it enjoys a type of preferential treatment as long as
"TCP Friendly" UDP isn't widely used.

Regarding: "treating all streams from a "single application instance" as
an aggregate managed in toto, requires the real-time imputation of
intent which is generally only available in retrospect," I would point
out that it's sufficient to treat all streams from a given class of
application as an aggregate, which we do at layer two in a number of
ways that don't require supernatural knowledge, such as VLAN tags. At
layer three and above, we can do this with DSCP or by real-time packet
inspection of various kinds, both "Deep" and "Shallow".

Others have criticized the Commissioner for proposing that engineers
solve engineering problems by reducing the statement to various forms of
caricature. I think what the Commissioner has in mind is that engineers
should solve the P2P problem in the forums where engineers meet and
develop solutions to hard problems. Two that are currently active are
the DCIA's P4P Working Group, where Comcast, Pando, BitTorrent, and the
Telcos are hard at work, and the IETF, where a proposed P2P
Infrastructure group is holding a BOF under the direction of ALTO. This
is happening this week in Dublin.

There's nothing particularly nefarious about these goings-on. In the
past, the Internet has needed various tweaks to deal with Innovative New
Applications that stressed IP, such as FTP and HTTP 1.0, and these
stresses have been relieved by a combination of fatter pipes and
adjustments at Layer 4 and above. There's nothing new going on here,
except for some long-deferred work being done on per-user fairness.

RB

David Farber wrote:
> ________________________________________
> From: Mike O'Dell [mo@ccr.org]
> Sent: Monday, July 28, 2008 6:46 PM
> To: David Farber
> Subject: Re: [IP] FCC Commissioner: "Engineers solve engineering problems"
>
> it's interesting that the Commissioner's op-ed piece proceeds from
> apocrypha exhibiting a fundamental factual error:
>
> Jacobson's Congestion Avoidance Algorithm does *not* "prioritize
> applications and content needing 'real time' delivery over those
> that would not suffer from delay."
>
> that would have been "IntServe" - the failed Integrated Services model
> promulgated in the IETF half a decade later which was never viable
> at the scale of the Global "Big-I" Internet.
>
> No, Jacobson's algorithm made all TCP streams on the same path tend to
> share more or less equitably when viewed over a relatively long
> interval.
>
> as has been reported before ad nauseum, the behavior being complained
> about these days is an application simply using multiple TCP streams,
> each one of which gets treated independently.
>
> as is often the case, the network behavior which some claim to desire,
> treating all streams from a "single application instance" as an
> aggregate managed in toto, requires the real-time imputation of intent
> which is generally only available in retrospect.
>
> if one possessed an algorithm which could read minds and tell the future
> to the degree required by that, one could find better uses for it
> than simply managing TCP flows. (grin)
>
>      -mo
>
>
>
> -------------------------------------------
>

--
Richard Bennett




-------------------------------------------