[Tfug] Ethernet frame "immutables" wrt switch silicon

[Bexley Hall]

Hi Louis,

On 5/12/2013 9:22 PM, Louis Taber wrote:
> On Sun, May 12, 2013 at 2:29 PM, Bexley Hall<bexley401 at yahoo.com>  wrote:
>>
>> [Should a switch be able to *fix* a bad CRC when it retransmits??]
>>
>> It can't.  CRCs contain no error correction information.

Yes, sorry -- I am mixing this with another, different (but related)
discussion on the same topic (the other discussing implementation
issues).

The point I had wanted to make *here* was whether the switch should
"act as a wire" or "have smarts".

>>   At a minimum, if the switch can do a cut through, it will
>>> need to see the destination MAC address prior to sending the packet
>>> forward.
>>
>> There still is buffering present in a cut through -- it's just
>> not "deferred" to the extent that it might otherwise be (e.g.,
>> in the case where the destination port is busy at the time).
>>
>>   Does anyone know of a switch that can do a cut through on
>>> broadcast packets to available ports while using a store and forward
>>> strategy for the remaining interfaces?  - Louis
>
> I sincerely doubt any manufacture would bother.  As the switch gets larger
> it makes more sense, but as a switch gets larger it also needs to deal with
> virtual networks as well.  And if the broadcast packet is bad,  it will be
> sending bad packets to most recipients

A switch that supports cut-through also has to support store and forward
cuz the targeted port may not be available to propagate the frame to
be "cut through" (else, the switch effectively creates a collision
where none "physically" exists).

>> OTOH, I can't see why a switch wouldn't do this as a natural
>> consequence of its design -- it decides whether to cut through
>> or store based on how busy the destination i/f is... why would
>> it not use a similar algorithm when processing an incoming broadcast
>> packet?  I.e., "get this packet out *your* port as soon as it
>> makes sense to you..." (regardless of what the other ports are
>> doing, now)
>
> How a switch manufacturer assures that each port gets the packet will
> vary.  Mixing cut-through and store and forward will complicate the design,
> and my guess, to little advantage.

It increases the overall throughput of the switch.  Cutting through
decreases the latency for the frame in question (wrt that outgoing
port).  Latency translates to "lost bandwidth" if the port is otherwise
idle during this period.

Note that the switch is a perfect example of "step and repeat" in
a design -- you're just doing the same thing on each of the N ports
so any economies in your design are immediately magnified.

I haven't yet thought through all the consequences for PTP switches
but don't see why this couldn't be handled in the same way the
"to-cut or not to-cut" implementation would be...

(And, I haven't thought through the boundary cases for PoE switches
when the PD's are coming *up* at the time traffic is destined for them!)