[e2e] Internet packet dynamics

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Sun Mar 14 22:14:52 PST 2004


In missive <20040314225840.GA24158 at lcs.mit.edu>, "David G. Andersen" typed:

 >>  Oftentimes it is.  It depends wildly on the connection,
 >>though - voip over DSL would probably be unpleasant without
 >>a DSL router that supported QoS.
 

of course the right way to do voice of DSL is to use the ATM multiplex, and then pop the voice out at the POP and
THEN packetize it in IP where the linespeeds are enough that the serialisation delay, and queueing
delay jitter  are much less:)

 >>  Some of the high loss periods were short outages, and some of them
 >>were congestion.  I didn't break them down in the paper since it's
 >>hard to distinguish with low-rate probing, but it would be
 >>interesting data to see.
 >> 
 >>>   One quick question. In your paper, you seem to suggest that sending
 >>> the same packet back-to-back along the same path get about the same
 >>> benefit as sending packets along different paths. If the packet loss is
 >>> caused by congestion, aren't you aggravating the congestion condition by
 >>> doubling your transmission rate?  And isn't it going to increase the
 >>> packet loss rate?
 >>
 >>  Depends on the cause of the losses.  My conclusion from the
 >>paper was that using different paths was more effective against
 >>outages (long-lasting or transient), but that a 20ms spacing between
 >>packets was nearly as effective as using alternate paths when trying
 >>to combat congestion.  This makes some sense if you believe that most
 >>congestion probably occurs at the access links.
 >>
 >> Aren't I aggravating it by sending twice?  Absolutely. :)
 >>I don't think that the basic mesh scheme is appropriate for bulk
 >>transfers.  I think it's great for low-rate control traffic, SNMP
 >>data, and streams where you were planning on sending them at a fixed
 >>bitrate anyway (like the air traffic control example from the  
 >>original Mesh paper at SOSP 2001).  Some of our newer work
 >>looks at the benefits of applying duplication _very_ selectively - 
 >>to, say, TCP SYN packets and DNS packets - and it turns out that that's
 >>a huge win without imposing awful amounts of overhead or impairing
 >>friendliness.
 >>
 >>  -Dave
 >>> 
 >>>   Thanks,
 >>> 
 >>> Sam
 >>>   
 >>
 >>-- 
 >>work: dga at lcs.mit.edu                          me:  dga at pobox.com
 >>      MIT Laboratory for Computer Science           http://www.angio.net/
 >>

 cheers

   jon




More information about the end2end-interest mailing list