RE: [RPRWG] More comments on preemption
But in case RPR MAC does preemption, that responsibility has to come to
MAC (like retry in half duplex collision cases). Or
you are suggesting to loose that packet and let TCP try it out ?
Regards,
Devendra Tripathi
VidyaWeb Inc.
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: Yongbum Kim [mailto:ybkim@xxxxxxxxxxxx]
> Sent: Friday, May 04, 2001 11:06 PM
> To: Devendra Tripathi; jeanlou.dupont@xxxxxxxxxxx; Raman Venkataraman
> Cc: William Dai; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] More comments on preemption
>
>
> A correction, Devendra. Ethernet does not re-transmit
> on FCS error. IP does, after considerable ack/nack delay.
> RPR, I presume, does not keep a packet around to re-transmit
> on FCS error either.
>
> Yong.
>
> ============================================
> Yongbum "Yong" Kim Direct (408)922-7502
> Technical Director Mobile (408)887-1058
> 3151 Zanker Road Fax (408)922-7530
> San Jose, CA 95134 Main (408)501-7800
> ybkim@xxxxxxxxxxxx www.broadcom.com
> ============================================
>
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
> Behalf Of Devendra Tripathi
> Sent: Friday, May 04, 2001 11:17 AM
> To: jeanlou.dupont@xxxxxxxxxxx; Raman Venkataraman
> Cc: William Dai; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] More comments on preemption
>
>
>
> > * Arbitrary artefacts: this type of artefact can be supported
> by the same
> > framing methods (HDLC, 8B/10B). The HDLC layer has an "ABORT"
> > code standardized
> > for example.
>
> Actually, this is what I thought when pre-emption was suggested first. By
> creating a CRC error (Ethernet case), we essentially re-transmit
> the packet.
>
> Regards,
> Tripathi.
>
>
>
>