[e2e] [tcpm] RTTM + timestamps

[Scheffenegger, Richard]

HI Alex,


> > o) RTT variance during loss episodes is not deeply researched.
> > Current heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988)
> > explicitly exclude (and prevent) the use of RTT samples when loss
> > occurs.
> 
> Eh... With RFC1323, you take RTT samples when loss occurs.

True, but these samples are a worst-case upper bound, since the last
in-sequence delivered segment - if you are running "stateless" on the
sender. With a stateful sender, that keeps sending timestamps
independent of the TS option, and matches the (S)ACKed packets to this
(potentially very lengthy) list, you can - to some extent - circumvent
this issue.

However, it does not help you with re-retransmissions still.

Probably my wording was poor, what I intended to say was to get the best
possible RTT measurement with each delivered (and (S)ACKed) segment
possible, without incurring undue overhead (state) in the sender.

The deliberate withholding of TS info according to RFC1323 - in order to
address the problem of unreliably delivered ACKs, and - at the time -
non-availability of SACK, was what triggered this point.


> >  However, solving the retransmission ambiguity problem -
> 
> The problem is solved, isn't it? Eifel?


Only for cumulative/partial ACKs, and only then in theory, because IPR
restrictions prevent Eifel from being deployed in any commercial stack.
(There is only a single OS compatible with the IPR requirements for all
the Eifel algorithms).

For segments that are delivered out-of-sequence, it still exists.

> 
> > and the related reliable ACK delivery problem - may allow the
> refinement of these algorithms further, as well as enabling new
> research to distinguish between corruption loss (without RTT / one-way
> delay impact) and congestion loss (with RTT / one-way delay impact).
> 
> This is not new. Ask Michael Welzl ;-)
> 
> And a citation form Sally Floyd to that topic:
> 
> "Inferring congestion vs. corruption at the transport level. There are
> also papers that investigate algorithms for the transport end-nodes to
> infer that certain drops are from corruption rather than congestion,
> without explicit feedback from routers. My own view would be that the
> burden is on such approaches to show that they are not ignoring
> legitimate congestion indications from the network."
> 
> eg: S.Biaz and N. Vaidya. Discriminating Congestion Losses from
> Wireless Losses Using Interarrival Times at the Receiver. IEEE
> Symposium on Application-Specific Systems and Software Engineering and
> Technology, Mar 1999.

Thanks for the reference! Still you need some way of getting most
accurate RTT samples back to the sender, right?

> > o) Retransmission ambiguity detection during loss recovery
> 
> (what we already have)

Not really, you'll not get a lower TS back for a long delayed segment,
which was already retransmitted; also, if the retransmitted segment is
beyond some (still existing hole), Eifel + RFC1323 still fail to
disambiguate between original and retransmitted segment, when it's
delivered.

> 
> > would allow an additional level of loss recovery control without
> reverting to timer-based methods.
> 
> I don't get this point.

Ok, this revolves around lost retransmission detection at the
end-of-stream / below RecoveryPoint. First, LRD is again not widely
available (only one particular stack has that feature), nor officially
specified. Second, it depends on the ack of a segment beyond recovery
point to find that a retransmission was lost.

However, if the sender can infer the exact ordering in which all the
segements (original, retransmitted, reordered,...) were delivered to the
client, it can make a more informed choice if one particular segement
was lost (again), before going beyond RecoveryPoint (ie. Retransmit as
soon as the segment re-transmitted (!) dupthresh segments later than the
one in question, is received; For emphasis, I really mean the
re-transmitted segment, not the the delivery of a delayed original
segment (because that would be in indication, that there is a good
chance of the still-lost segement to be delivered via a slower path;
re-sending then would violate the packet conservation principle).


> 
> > As with the deployment of SACK, separating "what" to send from
"when"
> to send it could be driven one step further. In particular, less
> conservative loss recovery schemes which do not trade principles of
> packet conservation against timeliness, require a reliable way of
> prompt and best possible feedback from the receiver about any
delivered
> segment and their ordering. SACK alone goes quite a long way, but
using
> Timestamp information in addition could remove any ambiguity.
> 
> Which ambiguity do you mean here?


Hope I made this clear already: For out-of-sequence delivered,
retransmitted segments. Under certain circumstances, the sender may
re-transmit one segment more than twice, and it should be possible to
discriminate between each individual instance of that segment by using
SACK+TS information.



I can send around a sketch of such a less-conservative SACK loss
recovery scheme, using SACK+TS information, for detailed discussions
about it...?

Best regards,
   Richard