I think the example is still too generic.

First thing is, if your service has 7 call layers, maybe it's just too deep.

Second thing is, I found that retry strategy works the best if you define it based on what the nodes are actually doing (instead of treating them as generic nodes). For example, if node D is a database failing a transaction, you may just configure it to retry the transaction instead of doing an application-initialized request resubmit, because the database probably knows better about why the transaction has failed than the application connected to it.

Third thing is, retry is worth it only when progress has been and/or can still be made. If the resources is no longer available forever, then there's no point of retrying.