Cell Relay Archive

[Saso STOJANOVSKI <sassos@res.enst.fr>]

pete,

On Wed, 23 Jul 1997, Pete Flugstad wrote:

> Saso STOJANOVSKI wrote:
> > 
> > what has cbr got to do with this?!?
> > 
> > for  data transfer you would use abr, i guess.
> 
> Assuming ABR/ER ever arrives and works, the latter being the 
> big question.


if one tries hard enough, then it will :)

 
> > and for *reliable* data transfer you would use sscop-over-abr.
> 
> Except that ABR will result in highly-variable RTT times.  This is one
> of the *major* short-commings of SSCOP - it does not deal well with
> variations in delay across a network.  It has fixed timeouts, and
> if they are not met, it pukes.  TCP does this in spades, has done
> this in spades for 15+ years.


well, i think this point is well worth discussing. 
since i have no hard data at the moment, here i express only my reflexions
and i would like to read a feedback on them. 

i) it is true that sscop has fixed timers. the 2 most important timers
are: no_response_timer and poll_timer (keep_alive_timer and idle_timer are
not that interesting for the story, in my opinion).

poll_timer is used to trigger a polling message. 

even if this timer times out because of the delay variation in the
network, i hardly see any problem. the timeout will generate a *poll
message*, not a *retransmission* as in tcp. furthermore, the transmitter
can continue pumping *new* data messages immediately after the poll
message, thus wasting no time while expecting the sollicited_status
message.

on the other hand, a polling message may also be triggered after a
number of data messages. in my opinion you can always choose a
sufficiently large value for the poll_timer and thus rely only on this
kind of a trigger.

no_response times out when something really goes wrong. its value is
rather larger than any expected delay variation.


ii) if (as you say) abr/er becomes a reality, then there would not be much
delay variation, would there?


iii) the sscop timers are a local matter. they could get readjustable, if
it turns out to be necessary. there will always be some new jacobson or
karn or whoever.


> Assuming the current ABR mechanism ever works, and doesn't collapse 
> under it's own weight.

if it collapses, then one should try abt/dt. it is much simpler.

> Well sure, if I *know* that both ends are connected to the same 
> ATM network, I'd use SSCOP over AAL 5, with *big* buffers (ABR
> is vaporware at this point).  However, what guarantee is there 
> that I'm going to *know* both ends are connected to the ATM.

you are not supposed to *know*. the setup message could negotiate this for
you (some bhli info element).

as for the *big* buffers: sscop has a local congestion mechanism - the
"lower_layer_busy" signal. therefore, sscop will not keep pumping data to
the atm layer senselessly; the data will remain on the *hard disk*, until 
necessary.

> In the real world, I'm talking IP over ATM - SSCOP does not enter
> in at all, other than to setup the connection to your local
> router.  You can talk all you want about an SSCOP based FTP, 
> but it isn't going to happen in a general (or even limited)
> way any time soon.

is this a prognosis or a wish?

seriously, i think that the role of sscop as a transport protocol is quite
underestimated. 

the nicest thing about sscop is that *it is already there*, in the
C-plane. so, why not use it in the U-plane, as well?

the other nice thing, when compared to tcp, is: *sscop has no congestion
control* and is not supposed to have one.

i agree that tcp is the only solution for the present. but with the advent
of atm workstations and multiplatforms such as winsock 2.0, why on
earth would somebody insist on using tcp over an end-to-end atm connexion? 

tcp will become a "vieux jeu" :))

regards,
--sS