perfsonar development work

[Joe Metzger <>]

Sven & Jeff,
Another issue that keeps popping up is that almost all of the  
applications using our network
today have VERY asymetric flows.  Our usage is dominated by  
applications that are streaming
line rate (or disk rate), maximum MTU sized packets in one direction.  
In the other direction
we have half as many packets, and they are all tiny ACKs. (Or even  
more asymmetric if they are
using a UDP based file transfer protocol that does better ACK  
compression.)

We need one way tools to properly measure the effects that these  
asymmetric applications have on the
network.  Also automated tuning applications could/should behave  
differently for congestion of the
data stream vs congestion on the ACK stream.

--joe


On Aug 21, 2007, at 3:15 PM, Jeff W. Boote wrote:

> Hi Sven,
>
> Sorry - just noticed this. I skipped it earlier thinking it was a  
> JRA-1 issue only.
>
> Sven Ubik wrote:
> > Hi,
> > > > the question that is typically asked is
> > > > 1) why do we need OWD?
> > >
> > > .... instead of ping? The answer to this question would probably  
> > > be: If you
> > > have an asymmetric path where one direction is significantly  
> > > slower (or
> > > faster ;) ) than the other direction, you cannot see this with  
> > > ping, because
> > > ping measures only the round trip time.
> > > You need to measure both directions seperately to find out such  
> > > behaviour.
> > I think this describes what OWD measurement does, but not why we  
> > NEED it. In my opinion importance of OWD is sometimes overstated,  
> > RTT is usually enough to assess effect of delay on throughput. It  
> > is rather hard to find an application that would really benefit  
> > from OWD instead of RTT. I think that one use of OWD (or detection  
> > of assymetry in delay)
>
> I'll give you 2 off the top of my head. I'm sure you also thought  
> of these, but don't think OWD is really needed.
>
> 1) real-time remote device control
> 2) video/audio conferencing
>
> These two applications probably only account for a small percentage  
> of the packets on our networks, but I suspect they account for much  
> higher percentage of the perceived value (and performance).
>
> > could be in assessing whether router queues fill up, which a sort  
> > of TCP implementations starting from Vegas unsuccessfully tried to  
> > do using RTT.
>
> It is IPDV that is useful. But, you can't get that without OWD.
>
> I would suggest that you have been able to get by just fine with  
> RTT only because of two things:
>
> 1) End hardware for these applications has typically introduced  
> more packet variation than the backbone networks.
> 2) Typical paths have been short enough that introducing a  
> relatively large 'jitter buffer' has not been too cumbersome.
>
> I am not convinced these conditions will continue to hold true.
>
> jeff