[e2e] [tcpm] RTTM + timestamps

Alexander Zimmermann alexander.zimmermann at comsys.rwth-aachen.de
Sat Jul 30 06:59:45 PDT 2011


Detlef,

why do you hijack this thread? This is a TCPM not an e2e thread! Nobody can follow crazy cross-posting.

Sorry, you waste my time. I don't reply on this.

Alex


Am 30.07.2011 um 13:43 schrieb Detlef Bosau:

> Just see this post.
> 
> On 01/17/2011 03:35 PM, Alexander Zimmermann wrote:
>> Eh... With RFC1323, you take RTT samples when loss occurs.
> 
> You don't take anything, particularly no RTT samples, when loss occurs.
> 
>>>  However, solving the retransmission ambiguity problem -
>> The problem is solved, isn't it? Eifel?
>> 
> 
> The timer ambiguity was originally solved by Karn & Partridge. To my understanding, this ambguity does not even occur when timestamps are used. Do you agree?
> 
> 
>> 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.
> 
> There are lots of papers in that direction, however, I don't see a reasonable way to infer the true reason for a concrete packet loss on an end to end basis.
> 
> And that is a different story from RTT sampling.
> 
>> 
>> 
>>> 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?
> 
> Again, I think, Eifel solves a different problem.
> 
> Eifel deals with dectecting spurious timeouts.
> 
> -- 
> ------------------------------------------------------------------
> Detlef Bosau
> Galileistraße 30	
> 70565 Stuttgart                            Tel.:   +49 711 5208031
>                                           mobile: +49 172 6819937
>                                           skype:     detlef.bosau
>                                           ICQ:          566129673
> detlef.bosau at web.de                     http://www.detlef-bosau.de
> ------------------------------------------------------------------
> 
> 

//
// 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: 243 bytes
Desc: Signierter Teil der Nachricht
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20110730/497e0bb3/PGP.bin


More information about the end2end-interest mailing list