[e2e] [tcpm] RTTM + timestamps

[Alexander Zimmermann]

Hi Richard,

some rash thoughts...

Am 17.01.2011 um 14:48 schrieb Scheffenegger, Richard:

> Hi group,
> 
> After having received some feedback off-list so far, I would like to summarize what I learned so far. Also, I invite everyone to discuss these points. There are benefits for the research community both empirical as well as theoretical, as well as mobile and high-speed network operators and implementers.
> 
> 
> o) one-way delay based (and delay variation based) congestion controls would benefit from knowing the clock resolution on both sides. Some research in that area is done by Mirja Kuehlewind and Bob Briscoe (http://bobbriscoe.net/pubs.html#chirp_impl), as well as David Hayes (http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf)
> 
> 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.

>  However, solving the retransmission ambiguity problem -

The problem is solved, isn't it? Eifel?

> 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.

> This appears to be a rather neglected field however, especially when it comes to large scale, public internet investigations. Due to the very nature of this, passive investigations without signals contained within the headers are only of limited use in empirical research here.
> 
> o) A side-effect of Van Jacobson's algorithm is that RTO spikes when the path RTT suddenly drops. With the decrease of the path RTT, the variance grows. As the variance has a large effect on the calculated RTO, this leads to potentially very lengthy timeouts even though the RTT is much shorter. This particular problem has been addressed in some stacks, and the lessons learned from the deployment there could be used to update the RTO calculation specs.
> 
> o) Enabling of spurious RTO detection (Eifel, D-SACK, F-RTO) in the last years also make it possible to dynamically identify instances when the RTT estimation or RTO calculation where mislead, allowing to use a more conservative algorithm for certain paths / times.
> 
> o) Retransmission ambiguity detection during loss recovery

(what we already have)

> would allow an additional level of loss recovery control without reverting to timer-based methods.

I don't get this point.

> 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?

> However, the current specs in RFC1323 make that use impossible, thus a modified signaling (receiver behavior) is a necessity.
> 
> 
> 
> 
> 
> The first central aspect of the above mentioned points is to resolve the retransmission ambiguity

Again, Eifel?

> , and the second to give the end host a better understanding of their respective partners behavior.
> 
> I strongly believe that much about the retransmission ambiguity can be solved by exploiting synergistic signaling between the TCP SACK option and Timestamp option. In particular, the receiver-side state required by RFC1323 to choose which Timestamp to reflect when a non-contiguous segment is received could be alleviated, when the TCP session is also using SACK. (The presence of a SACK field indicates some out of sequence delivery. The current stipulations were made, afaik, to ensure that no unduly small RTT sample is entered into the RTO calculation, when ACK loss occurs. But again, SACK disambiguates between a in-sequence ACK, and a duplicate ACK).
> 

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann at cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: Signierter Teil der Nachricht
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110117/b1825a84/PGP.bin