[e2e] Is a non-TCP solution dead?

[Cannara]

Love that touch Lloyd -- it's required on some other lists, believe it or
not.  By the way, you know we can assess how any alternate transport might
improve over TCP by noting what's been removed -- if slow-start isn't there,
then it's relatively easy to estimate; if delayed-ack is gone, ditto; same for
other changes to backoff.  In fact, someone could simply recompile NS with
items commented out, unless it's too spaghetti like.  :]

I'll see what I can make of an XCP/FAST comparison, as an exercise for
students.  Might be good.

Alex

Lloyd Wood wrote:
> 
> On Tue, 8 Apr 2003, Dave Crocker wrote:
> 
> > Cannara,
> >
> > C> Dave, you can call me as I sign -- Alex
> >
> > my email software automatically takes what you supply in your From
> > field.
> 
> Gee, nothing like the personal touch.
> 
> Crocker,
> 
> How does your software distinguish between Euro style familiar-name
> family-name ordering and Asian style family-name familiar name
> ordering?
> 
> Cannara,
> 
> pray give us your loss-related evaluations of Dina Katabi et al's XCP
> (more traditional control theory framework, generalised from ECN with
> router state, not TCP-compatible) and S.Low et al's FAST
> (utility function framework, vaguely descended from TCP Vegas.)
> 
> If we're going to discuss TCP sucktitude, it would be nice to be able
> to relate it to current research.
> 
> thanks,
> 
> L.