Subject: RE: [Diffserv] Comments on VW EF draf

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Mar 2000 16:47:06 -0600

Shahram 

You'll love this: I didn't read it. I just answered what was obvious about
Traffic Engineering and IP based Voice Codecs from your questions. If this
wasn't in the I-D then shame on the authors; it didn't take much text and
apparently explained adequately for you what was intended to be conveyed.

Hopefully they're reading this....

At 02:09 PM 3/27/2000 -0800, Shahram Davari wrote:
>Hi James,
> 
>Thanks for your reply. Don't you think these assumptions for G.711 coding
>should be incorporated in the draft?
> 
>Regards,
>-Shahram
> 
>
>-----Original Message-----
>From: James M. Polk [mailto:[email-masked]]
>Sent: Sunday, March 26, 2000 11:58 PM
>To: Shahram Davari; [email-masked]
>Subject: Re: [Diffserv] Comments on VW EF draf
>
>
>Shahram 
>
>In IP, using a G.711 codec with Zero silence suppression-- with the
>IP/UDP/RTP headers (40 byte header to go along with the 160 byte payload) --
>it does require 80kbps with a 20ms clock (the math proves it). TDM doesn't
>require any headers, just sample rate, so it is just payload. Why IP Header
>compression isn't included for comparison is likely because (#1) that isn't
>Routable, (#3) RFC2508 is for Point to Point links -- not Switched or
>multipath, (#3) Incurs a Latency hit in the set up of the header information
>at both ends of a Point to Point Link, (#4) is (I believe) only used between
>Layer 3 devices because that's what you're compressing because of the
>requirement for L3 awareness.
>
>Keep in mind that in the 80kbps calculation -- NO Layer 2 headers are
>accounted for (something I've never agreed with when people use this
>throughput value). You will always require a L2 Header -- although it might
>change with the type of media you use on a per link basis. Ethernet is the
>worst with this -- but basically the fastest transport (so it doesn't matter
>as much) at (I believe) approximately 126kbps throughput for a G.711 codec.
>
>All that said -- I'm merely arguing the facts of IP Codec theory (and
>application) and have no other biases towards advocating or rebuking what is
>written in this draft.
>
>At 02:20 PM 3/26/2000 -0800, Shahram Davari wrote:
>>Hi,
>>
>>I have a few questions/comments on the VW-BA draft:
>>
>>1) In section 2.6 the voice capacity of IP network is compared to that
>>of a TDM Telco trunk, and it was concluded that there is a 25% BW
>>penalty for IP. However, it is not clear why for IP a 200 byte per 20 msec
>>(equivalent to 80 kbit/sec rate) is assumed, while for the TDM a 64Kbit/sec
>>rate. Is this overhead due to RTP/UDP/IP header? if so why header
>>compression is not considered for the comparison?
>>
>>2) Section 6.1.1.1 says that:
>>
>>"in order to get the worst jitter a packet from each ingress must arrive at
>>each of the M border routers at the same time and must be transmitted to
>the
>>interior router queue for the bottleneck link B at the same time"
>>
>>Since this section is about dumpbell bottle neck, why is it necessary for
>>the packets to arrive at the ingress routers at the same time? to achieve
>>the worst jitter case we only need the packets to arrive at the 
>>bottleneck at the same time, don't we?
>>
>>3) Section 6.1.1.1 says "bottleneck B" while the figure shows the
>>bottleneck link as "L". Which one is correct?
>>
>>4) Section 6.1.1.1 says: "The links between the border routers and the
>>bottleneck router must be enough larger than B that the packets are
>>still sitting in B's queue when our (A,Z) packet arrives at the end of
>>a burst of N, that is L>NxB"
>>
>>- What does B's queue mean does it mean the queue for the bottleneck L?
>>
>>- instead of the sentence "must be enough larger" isn't it better
>> to say "must be just large enough".
>>
>>- How is the L>NB equation derived? It doesn't seem correct to me because,
>>if L is infinitely large, then any packet arriving at bottleneck won't see
>>any other packets in front of it.
>>
>>According to my calculations if you have M links arriving at the
>>bottleneck point and each carrying a burst of N packets, then in order
>>for the last packet in a burst to experience jitter due to the other
>>packets in front of it, the time to transmit one packet over bottleneck
>>link "L" must not exceed the time that it takes to receive a burst of
>>N packets. That is:
>>
>>S/L < NS/B  =>  L<B/N
>>
>>4) Last paragraph of section 6.1.1 says " the amount of time to send an
>>EF packet on each link can be written as fT/(total no. of EF-marked flow
>>crossing the link). Is this always true. Don't you think that this holds
>>only when the full f% capacity of the link is used by EF.
>>
>>5) Section 6.1.1.2 finds the worst case jitter as fT. But the implicit
>>assumption is that an EF flow won't encounter another EF flow more than
>>once. However, in multipath routing an EF-flow may encounter another
>>EF flow many times. For example consider the following scenario:
>>
>>          X                    X
>>     /--------->\          /-------->\
>>    /            \        /           \
>>-->A              B----> C             D------>
>>    \            /        \           /
>>     \--------->/          \-------->/
>>         Y                      Y
>>
>>Flow X and Y encounter each other more than once.
>>
>>
>>I appreciate the authors reply.
>>
>>Regards,
>>
>>-Shahram
>>
>>_______________________________________________
>>diffserv mailing list
>>[email-masked]
>> http://www.ietf.org/mailman/listinfo/diffserv
><http://www.ietf.org/mailman/listinfo/diffserv> 
>>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
><http://www-nrg.ee.lbl.gov/diff-serv-arch/> 
>>
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
>www.cisco.com <http://www.cisco.com/>  
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 27 Mar 2000 17:05:24 -0800

"James M. Polk" wrote:
... If this wasn't in the I-D then shame on the authors; ...

Well, gee, that's constructive. 

Getting a draft -00 out on time, particularly when Van
Jacobson is the main author is not always easy. Things
get left out. That's why it's version -00.

Most of the list comments should get answered in today's
WG meeting and we'll post the slides afterward.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Mar 2000 01:03:07 -0600

Kathie

I guess tongue and check is gone from this list? 

I apparently should have put a smiley face   "  ;-)   "    at the end of that
sentence -- it was total sarcasm -- but there unfortunately is no vocal
inflection associated with email yet, is there.

shame on me.....

Van, I'm sorry if I offended you.

James M. Polk

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 29 Mar 2000 03:05:52 -0800

> I guess tongue and check is gone from this list?

Hey, emoticons can be useful. One's sense of humor
can get stretched trying to get Van to do something
on time.

> 
> I apparently should have put a smiley face   "  ;-)   "    at the end
> of that sentence -- it was total sarcasm -- but there unfortunately is
> no vocal inflection associated with email yet, is there.
> 
> shame on me.....
> 

I doubt if Van's offended. He's embarassed that he
left so much stuff out because I made him send in the draft
on time.