Introduction
The USB 3.0 spec requires the sender of any Header Packet to store a copy of it until it’s acknowledged, so it can be retransmitted in case it didn’t arrive to the link parter (more on different SuperSpeed packets on this page).
But what if a Data Packet Header (DPH) is rejected with an LBAD? Of course it must be retransmitted. But there was a Data Packet Payload (DPP) that went along with it. Should it be retransmitted as well, along with the retransmitted DPH? The spec isn’t clear about that.
Hints from the spec
The USB 3.0 spec does say a few things on the matter however (the emphasis in bold was added here):
Section 3.2.3 (Protocol Layer): “Data packet payloads are not delivered reliably through the link layer (however, the accompanying data packet headers are delivered reliably). The protocol layer supports reliable delivery of data packets via explicit acknowledgement (header) packets and retransmission of lost or corrupt data.”
Section 7.2.4.1.2: “Header packet transmission may be delayed. When this occurs, the DL bit shall be set in the Link Control Word by a hub and optionally by a peripheral device or host”. Among the reasons given for such delay: “When a header packet is resent”. And then goes further (to add confusion): “Note: The delayed bit only has significance if it is set in an ITP.”
Section 7.2.4.1.3 is more definitive: “Prior to resending a header packet, a port shall set the Delay bit within the Link Control word and re-calculate CRC-5.”
Also in section 8.3.1.4, Table 8-2, defining the DL bit: “This bit shall be set if a Header Packet is resent or the transmission of a Header Packet is delayed.”
Section 7.2.4.1.9: “If the retried packet is a DP and the DL bit in DPH is clear, the DPH must be followed by a DPP”
Section 8.11.2 (Host Response to Data Received from a Device): A DPP Error includes the option of “DPP missing”, and the response is “Discard data and send an ACK TP with the Retry bit set…” — no drama here.
Section 10.7.6.3 (on hubs): “After transmitting the end framing symbols for the data packet payload and required SKP ordered sets, the port may remove the data packet payload from hub storage. A hub shall not retransmit a DPP packet under any circumstances.”
Section 10.1.6.1 (on hubs): “In rare occurrences where data packet payloads are discarded because buffering is unavailable, the end-to-end protocol will recover by retrying the transaction”
Section 10.7 (on the hub repeater’s role): “Forwards data packet payload to upstream port if present”
Section 10.7.8.4 (on hub’s Header Packet processing): “If the header packet is routed to a downstream port that is not in U0… If the header packet is a data packet header the corresponding data packet payload is discarded.”
So the spec mentions dropping the DPP in certain situations, and says nowhere that the DPP should be retransmitted. So one can get the impression that the DPP should not be retransmitted.
In practice
For reference, this is what an Intel Motherboard’s USB 3.0 root hub does: It sets the DL bit on retransmitted header packets, whether it’s due to an LBAD or after Recovery, and doesn’t retransmit the DPP.
This is an example of how an Intel motherboard responded to an LBAD on a SETUP DPH/DPP pair:
07b5e7c0 00 00 00 00 00 00 00 00 fb fb fb f7 08 00 00 00 |................| 07b5e7d0 00 80 08 00 00 00 00 08 0f 3e 03 50 5c 5c 5c f7 |.........>.P\\\.| 07b5e7e0 00 05 01 00 00 00 00 00 6b 23 46 fc fd fd fd f7 |........k#F.....| 07b5e7f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 07b5e8e0 00 00 00 00 00 00 00 00 fe fe fe f7 00 39 00 39 |.............9.9| 07b5e8f0 fb fb fb f7 08 00 00 00 00 80 08 00 00 00 00 08 |................| 07b5e900 0f 3e 03 02 00 00 00 00 00 00 00 00 00 00 00 00 |.>..............| 07b5e910 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 07b5ea10 00 00 00 00 00 00 00 00 fe fe fe f7 00 39 00 39 |.............9.9| 07b5ea20 fb fb fb f7 08 00 00 00 00 80 08 00 00 00 00 08 |................| 07b5ea30 0f 3e 03 02 00 00 00 00 00 00 00 00 00 00 00 00 |.>..............| 07b5ea40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The original DPH (in green) followed by the DPP (in blue) is retransmitted (in orange) after an LRTY (in black bold). There is no retransmitted DPP.
The LBADs from the link partner was injected artificially for this experiment — there are no errors in the packets shown above.
Note that the DL bit is cleared in the original transmission, but set on the retransmission.
Conclusion
When implementing an USB 3.0 port, set the DL bit on the retransmitted DPH, and don’t bother retransmitting the DPP immediately afterwards. Let the link partner request the missing DPP explicitly with a Protocol Layer ACK, as it’s required to do per USB 3.0 spec section 8.11.2.
