Cell Relay Archive

[Jim Jackson <jj@scs.leeds.ac.uk>]

On Wed, 23 Jul 1997, Saso STOJANOVSKI wrote:

> 
> On Wed, 23 Jul 1997, Jim Jackson wrote:
>  
> > On 23 Jul 1997, Saso STOJANOVSKI wrote:
>  
> > > start forgetting tcp. 
> > > 
> > > think of using sscop in an end-to-end fashion.
> > > 
> > 
> > Why? Surely any reliable data xfer mechansism cannot be used for all
> > traffic. CBR etc needs mechanisms for ignoring/interpolating data loss,
> > not hanging about waiting for sscop or tcp to timeout and arrange
> > re-transmissions - the moment in time  for the data will have past.
> 
> 
> what has cbr got to do with this?!?
>  
> for  data transfer you would use abr, i guess.

I plead clumsy explession and guess you miss understood my drift here.

> and for *reliable* data transfer you would use sscop-over-abr

no TCP over abr - for the reasons I mentioned.

> > Why use an ATM only reliable data xfer protocol (sscop) when there is a
> > protocol implemented over virtually all media - it doesn't give you
> > anything, except a whole load of new headaches as you discover its quirks
> > and odd behaviour when really used in the real world. JUST because sscop
> > was chosen to be used in ATM networks for carrying the low bandwidth
> > signalling data, DOES NOT make it a good protocol per se. 
> 
> 
> sscop was designed to carry *well* either low-speed signalling data, or
> *very* high-speed data, in capacity of a transport (hence end-to-end)
> protocol.

Can you point to asny performance papers showing this wonderfull behaviour
of sscop in mixed real traffic environments? Or are we simply talking
artifical simulation reports here?

> sscop is *better* suited for atm networks, and this is not a secret. it is
> a selective-repeat rather than go-back-n protocol, and is not encumbered
> by the window adjustment mechanism of tcp (this is only a headache in atm,
> because congestion in atm is handled at atm layer - the abr automaton).

Sorry but abr does not fully reliably handle congestion - it attempts to
minimise it only.

> now, imagine you work on a station with atm card and you use a software
> based on a platform such as winsock 2.0. (this becomes more and more
> realistic).
> 
> imagine that you have to exchange a large amount of data with a fellow
> using the same kind of station.
> 
> you have the choice between two applications:
> 
>   a) a tcp-based ftp, or
> 
>   b) a sscop-based ftp.
> 
> which one would you use?

TCP because:

 it is universal and ubiquitously implimented

 its behaviour is understood, and there is loads of advise out there on
  how to configure it to make it work on fast networks.

> [hint: one of these combinations has a very naughty window-adjusting
> mechanism]

It's not naughty. It's a perfectly valid mechanism, and it workings are
pretty well understood. 

Jim Jackson
Project Leader
Leeds ATM LAN Pilot Project

PS We have 16+ OC3 ATM connected machines - we use direct some direct ATM
but mostly TCP/IP over ATM at pretty near wire speed when required!! Whats
the problem?

=======================================================================
Jim Jackson                                  Email :
School of Computer Studies	          Internet : jj@scs.leeds.ac.uk
The University of Leeds
Leeds, LS2 9JT, UK                           Phone :      0113 233 6794
=======================================================================