Re: draft-cameron-tmux-02.txt

[Pete Cameron <[e-mail]>]

---------  Received message begins Here  ---------

> From: "Donald E. Eastlake 3rd (Beast)" <[e-mail]>

> >The consensus of opinion at the Houston BOF was that the
> >document should be made very specific to terminal servers,
> >hence the direction I am taking. Also, it matters a LOT what
> >kind of packets are passed from the higher level to TMux. We
> >tried some experiments with ftp to see what would happen. If
> >we allow ftp packets to be multiplexed, then for a single
> >ftp session we got a 15% degradation in performance. We
> >consider this unacceptable for something that is designed to
> >increase performance. Having said this, I still agree to a
> >degree with your sentiments, TMux is applicable to all IP
> >trafic, but must be used with care.
> 
> Well, why was that?  You already recommend against tmux'ing large
> packets, which is reasonable.  Was it the delays in ACKs or something?

Yes, we believe that is the case.

> Even if this caused degradation for a single ftp session, would it have
> increased throughput if there had been 10 ftp sesssions?

It actually improved performance for 2 or more sessions to
and from a pair of hosts.

> It would be excellent if you could characterize what benefits most
> from tmux other than saying "terminal servers"...

My characterisation of the benefits, are on those protocols
where an increased delay is acceptable. In my view, these
are the protocols where people are the recipients of the
data. People can not notice short delays <50ms and accept
short delays <200ms. That is why we talk about login
sessions (changed to interactive sessions in next draft).


Pete