Subject: [Diffserv] Virtual Wire

From: Dan Grossman <[email-masked]>
Date: Mon, 20 Mar 2000 17:12:37 -0500

A few questions and a comment:
1) Is the point of VW 'no jitter' (as implied by the name, and some of the 
statements in sections 1 and 2) or 'jitter bounded to an engineered 
objective'?  I suspect that the latter is probably more accurate and offers a 
bit more flexibility to service providers to trade efficiency for QoS.

2) Similarly (and this echos a question from earlier), could there be multiple 
VW BAs in the same DS domain, marked with different DSCPs, and offering 
different jitter objectives?

3) Is there an unwritten assumption that B >> R (or n >> 1)?

4) Is there an unwritten assumption that the rates of all streams are either 
the same or integer multiples of each other?  The reason for this question is 
the observation that VW depends on a kind of self-clocking behavior to keep 
queues from building up.  The conjecture is that unless the streams are at the 
same rate, there will be constructive interference, so at times that are a 
common multiple of N sources' inter-departure times, there will be N packets 
in the queue. 

5) The Appendix correctly points out that the hop count is important in 
determining jitter bounds.  This is similar to the results that Anna Charny 
presented in DC for GS over AF.   Shouldn't this be discussed in the main body 
of the text?

5) Regarding the example in 2.6, there are a few little problems:
- presumably, the comparison is using 64 kbit/s PCM codecs.  Fair dinkum, and 
useful for comparison.
- the packet size is given at 200 octets.  That's 40 bytes of IP, UDP and RTP 
header, and no compression.  Again fair dinkum.
- a SONET link does not have 155 Mbit/s of useable bandwidth.  The useable 
payload for PPP over SONET is 149.760 Mbit/s.  Don't forget to deduct another 
.78 percent for byte stuffing, and 9 bytes per packet of PPP overhead (flag, 
address, control, CRC, flag). Total PPP overhead is about 2.2 percent in this 
scenario, so your usable link bandwidth is 146.4 Mbit/s.  
- for the comparison, I believe that there is no direct DS0 payload mapping.   
DS0s get mapped into DS1 (VT1.5) payloads, which get mapped to STS-1 which get 
mapped to STS3. The bottom line is that an STS3 is good for 2016 DS0s, not 
2421.

6) The example in the draft claims that the bandwidth penalty is 25%.  This is 
equal to the 25% packet header 'tax' (RTP payload/(RTP header+UDP header+IP 
header).  Is the point that there is no traffic engineering overhead required 
to support this BA, save for the 5-10% fudge factor?  

7) It appears that in the example, the limit shown as 1938 telephone calls is 
for the entire DS domain. Is my understanding correct?  If this is the case, 
isn't the scaling of this BA pretty limited?  Would route pinning or some kind 
of routing policy  massively improve  scalability?  

Still haven't absorbed the appendix completely.  Will probably have more 
questions in Adelaide.

BTW, for the next cut of the draft, would the authors please use the same 
notation?

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/