Transport protocols and bulk file transfer

[Steven Senger <>]

Attached are some notes that Larry Dunn took when he and I talked on 
the phone a few weeks ago about the transport needs of my app.

- steve


> >   041221 conf call w/ steve, stas; 800-541-1710 #0119319
>     > Notes from conversation to learn more about Steve's
>       app. an data requirements, etc.
>     >  stas couldn't make it
>     >  on buffering...
>         >  he's trying to see if there's a way to squeeze in  a couple
>            things for his apps (visible human segmentation- cf. URL at 
> bottom);
>         >  maybe making bad implementation guesses...
>     >  1 app: behavior:
>         >  fixed buffer space (2 seconds of traffic); the semi-reliable
>            would be on when to block the "send"
>         >  as long as transport_rate > date_gen_rate, nothing backs up
>            on the server
>         >  he sees loss-blips sometimes, pkts lost; currently: tries to
>            resend them, but depending on how long blip lasts, backs up
>            buffer
>         >  if so, the instead of blocking, replace oldest data w/ new
>            data (i.e. the oldest 2 seconds of traffic)
>         >  it's a visualization tool for exploring volumetric data;
>            client sends position, server streams out pixel update
>         >  typ. data rates: varies dep. on mode user operates in- some
>            small, some up to 25-30mbps per stream, server should 
> support
>            4-5 streams
>         >  so he'd like a packet/message layer, to preserve message
>            boundaries
>         >  stas-(previous chat): no reason to ever block on send, make 
> buffer
>            as large as you need, so never loss; (that's bad - it could 
> get
>            arbitrarily far behind you)
>         >  he could add rate-adaptive hooks at some point (like dunn 
> suggestion);
>         >  it's something he wrote in 1999 for transport- had multiproc
>            at nasa-ames; connectivity (then he was wisc-net to NREN);
>            TCP wouldn't work for him at all
>         >  he did make it run w/ mcast; uses UDP now, can do mcast.
>         >  at the time, UDT didn't exist, else he'd have tried that.
>         >  so if there's a way to squeeze that in to the new protocol,
>            that'd suit him; if not, fine- he does have an overall
>            congestion-control learning goal.
>         >  timed reliability of SCTP is almost the same, but they
>            assume an a priori knowledge of how long it's OK to stay in
>            queue.
>         >  app is Anatomical visualization (visible human)
>         >  now part of NGI project he collaborates on w/ stanford;
>         >  visu.uwlax.edu/ ngi, anatomy, immersive segmentation link;
>            full link information: http://visu.uwlax.edu/NGI/ImmSeg.html
> >   off @ 1:51p
>
> <end cut/paste>