The IP Over NBMA (ION) Archive

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

> >>But, though you mentioned CSRs in the draft, I don't think CSRs
> >>are useful for cell-by-cell communication of best effort traffic.
> 
> Ah. Okay..

So, with RSVP, CSR can still offer delay-less multi-sender multicast.

> >>Then, though you wrote:
> >>
> >>   A possible solution is for the CSR's underlying cell switching fabric
> >>   to provide AAL_SDU-aware cell forwarding.  If segmented AAL_SDUs
> >>   arriving from the source  Cluster  could  be buffered  and  forwarded
> >>   in groups of cells representing entire AAL_SDUs, the CSR would need
> >>   only a single SVC into the target  Cluster.
> >>
> >>it will create a packet delay worse than that of packet based
> >>relaying.
> >>
> >>That is, if you transmit a 800byte packet over a dedicated 64Kbps
> >>VC, packets from other sender are blocked 0.1 seconds.
> 
> I would buffer the incoming AAL_SDUs, but not block the outbound
> SVC.

My assumption is that we are using AAL5.

So, the outbound VC is blocked by other SDUs.

> Access to the outbound SVC would be FIFO - first complete AAL_SDU
> buffered on any incoming SVC would get access to the outbound SVC.

That's as good as packet relaying with multiple queues except
that inbound VCs are dedicated.

For the multi-sender best effort multicast, with a shared best effort
unicast VCs, which will have a lot wider babdwidth than dedicated ones,
packet reconstruction time and blocking delay is a lot less.

> Presumably if the outbound SVC was 64kbit/sec then you'd
> get the same delay whether it was a CSR or a conventional Mrouter.

If a CSR assigns two 32Kbps VCs (based on PATH messages) dedicated
to each sender, there is virtually no delay.

							Masataka Ohta