[e2e] a new IRTF group on Transport Models

[Cannara]

Anyone who is, or uses, a service provider will certainly have flows over
complex, crossing paths with multiple queues.  Haven't TCP simulation tests
taken this into account?  Can it be true they haven't?

Just a few weeks ago, a client had just such poor TCP performance through a
particular provider, and, lo & behold, it was simply small pkt loss interior
to the ISP's net, due to errors.  Then began the tedious process of proving to
Idiots.net that it was indeed their box.

Even corporate nets have a variety of crossing points with a variety of link
types & speeds, and a variety of office/site usage schedules.  All together,
these can create variable path characteristics, even within a second. 
Distinguishing congestion from error becomes extremely important when, for
example, the sales team is at a large customer and accessing important
presentation data at the home office in real time.  

Or maybe when your doctor is remotely monitoring your heart condition and
getting ready to do a robotic bypass as the robotic injection he just gave you
sends you drifting off...oops, TCP slowed down!
:]

Alex

> Douglas Leith wrote:
> 
> Following up on Frank's question, one area where I suspect more data would
> help is in defining  topologies to test TCP performance over.
> 
> Most work to date has focussed on a dumbell topology.  While this seems like
> a useful starting point, it would be good to have a better understanding of
> the range of end-to-end topologies experienced by TCP flows in practice.
> For example, it would be good to know what proportion of flows travel along
> paths where packets are queued at two or more hops (due to cross-traffic
> etc) and to better understand the character of such paths assuming they
> exist in appreciable numbers.  This seems to require additional measurement
> information from that which is currently available - probing from the edge
> alone can probably only yield limited/ambiguous information on what's
> happening inside the network and so router information might help out a lot.
> 
> Doug
> 
> -----Original Message-----
> From: end2end-interest-bounces at postel.org on behalf of frank at kastenholz.org
> Sent: Wed 6/8/2005 1:49 PM
> To: end2end-interest at postel.org
> Subject: Re: [e2e] a new IRTF group on Transport Models
> 
> While all this chatter about certain actions TCP can
> or can not take and perfect nets with theorem
> provers in all the routers is as interesting and
> amusing as brain surgery, my original question stands:
> 
>      Is there any thought to identifying information
>      that routers and end systems might provide that
>      either can be fed back into the models to refine
>      them or used in parallel to (in)validate them?
> 
> Frank Kastenholz