Subject: Re: [NEXTEL-1] Re: Subject: Re: "Hot-Spot"

From: Rick Parrish <[email-masked]>
Date: Fri, 01 Aug 2003 07:29:42 -0500

Todd Marshall wrote:

> I am astonished by these kind of comments. I have seen zillions of 
> dollars going into initiatives to try to give IP some QoS 
> characteristics. 

<snip> Todd - I think you will find that a lot more people are familiar 
with IP (internet protocol - not that other IP) terminology and 
functionality than with ATM. That said, it sounds like you've had some 
experience educating ATM-ignorant folks like myself. I think your 
discourse and the concept at large is excellent. Here's some minor 
nitpicking to an otherwise great explanation and arguement.

> Further, with IP, the relatively disciplined TCP throttles back (as in 
> "drops QoS") when confronted with a burst of totally undisciplined UDP 
> ... and most video goes UDP so it just squashes the voice. 

How can TCP be "confronted" with UDP? (BTW, I get annoyed when people 
say "TCP" when they mean IP in general). UDP just delegates the "QoS" 
issues to the application which can be good thing when you've got 
adaptive compression techniques at your disposal.

> The so called ATM cell tax is in the order of 15%. If we were really 
> concerned with that, would XML have any following at all? 

Most XML is sent over the 'net as a gzipped stream (ie. using LZ or 
huffman compression) so the verbose, redundant tags are easily squeezed. 
The zipping/unzipping is usually handled transparently by the software 
(as negotiated with HTTP headers, for example).

Of course, a 15% penalty doesn't sound too bad.

> Bigger IP packets would just travel even more empty. 

Huh? Empty IP packers? IP packets are variable length. The payload 
length is right there in the header. Do you mean ethernet?

<snip>

> The ATM model doesn't want to be trunked. It wants to be spread out 
> ... like in a web.

Cool.

<snip>

> They jam all the traffic together and then at each node they separate 
> it all back out again to redistribute it. And then jam it all back 
> together to move on to the next node. How can anyone say cell-tax with 
> a straight face after all that?

fascinating.

<big snip>

> And take the example of  video conferencing:  you create a call which 
> is a collection of connections. 

<snip>

If broadcasting goes away, then we still need to accomodate the content 
providers with a means for distributing popular content. Setting aside 
video conferencing, how about multi-casting something like CNN 
audio/video channel where the routing of the signal to multiple 
destinations is influenced by its popularity? I'd love to hear how ATM 
would handle this. Hopefully it isn't a whole bunch of discrete connections.

<another big snip>

Regards,
Rick

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Todd Marshall <[email-masked]>
Date: Sat, 02 Aug 2003 10:32:12 -0500

> adaptive compression techniques at your disposal.

TCP is UDP with discipline. It trys to make IP connection oriented (i.e. 
packets arrive in order with none missing). It competes for the same 
transport with the UDP. Drop a UDP packet and nobody and that's 
expected. Drop a TCP packet and, depending on the implementation, it may 
throttle its window back down to a single packet and retransmit. The UDP 
just keeps coming. Given enough competing UDP, the TCP can't flow at 
all. It keeps dropping packets and restarting. Not a very nice way to 
treat the polite one.

> Of course, a 15% penalty doesn't sound too bad.

My XML point was that people have been willing to give up 50% of their 
bandwidth for XML without a peep. With Base64 they give up 30% without a 
peep. Why should we expect a peep about ATM's 15%? Especially when it 
gives such superior QoS naturally.

Additionally, all those added IP protocols add tax to IP ... usually a 
quite high tax. All that chatter it needs to get and stay organized is 
not free. And IP looses much of its variable length, big payload, 
advantage when it deals with MTU's (maximum transport units) and when 
latency is an issue (like with VoIP). IP datagrams have 24 bytes of 
header. ATM cells have 5. ATM cells are 53 bytes. Datagrams would have 
to be bigger than 253 bytes to have a lower tax. IP MTUs can get as low 
as 125 bytes when you start dealing with QoS issues. At that point, the 
IP cell tax is 30%.

> length is right there in the header. Do you mean ethernet?

This link does a pretty good job of describing how voice gets onto ATM.
http://www.commweb.com/article/COM20010604S0014

I've clipped a pertinent part relating to the LD-CELP (Low Delay-Code 
Excited Linear Prediction)  compression

The next step varies, depending on the service provider's approach. 
Using the least efficient approach, the 10-bit value is placed into the 
payload of an AAL 2 cell, with stuff bits completing the fill of 48 
octets, and the cell is sent on its way.

A more efficient approach might call for four 10-bit values to be linked 
together and placed into the cell, with stuff bits completing the fill, 
and the cell is sent on its way. Each set of 40 bits represents only 
2.5ms of a voice stream, which is well within delay limits. As the 
number of 10-bit values increases and the number of stuff bits 
decreases, the technique becomes more and more efficient, although 
compression delay increases and the nature of the conversational voice 
communication can be affected in a very negative way. In any event, once 
filled, each cell is fired across the network.

ATM was invented for voice. The cells are small compared to IP packets 
because they need to be to meet delay restrictions. So how could you not 
expect IP to have exactly those same restrictions?

> would handle this. Hopefully it isn't a whole bunch of discrete 

ATM has protocols that support adding leafs to connections and thereby 
gaining some efficiencies in a multicasting context. However, I think 
what we'll really see is the WalMart distribution model. Content will be 
delivered to various remote points and then be redelivered from there on 
demand. It's much easier to implement such a model when you're dealing 
with bytes instead of TV sets. The Wireless ATM web, when it becomes 
ubiquitous, turns the broadcasting model on it's head. The reason we 
watch the 6:00 news at 6:00 is because that's when it's broadcast. The 
new model is the internet model. Broadcasting takes place when there is 
something to say. Viewing takes place at the viewer's convenience.

Regards,

Todd

---

From: Rick Parrish <[email-masked]>
Date: Sat, 02 Aug 2003 17:02:48 -0500

Todd Marshall wrote:

> to be bigger than 253 bytes to have a lower tax. IP MTUs can get as 
> low as 125 bytes when you start dealing with QoS issues. At that 
> point, the IP cell tax is 30%.

Most transport protocols "tunnel" IP by prefixing it with their own 
headers. I like the edge-translation mechanism you describe. There's no 
need for IP headers on ATM cells. The ATM connection remembers the IP 
header and adds it back on when the data pops out at the other end ... 
sweet!

Have you looked at HARP? Apparently, it's built in to most BSD kernels.
http://www.msci.magic.net/harp/harp2.html
Apparently, the carriers lobotomize ATM by using PVCs (permanent virtual 
connections) to bundle data. The HARP codebase suffers this same major 
limitation - it's built for ATM PVCs so it would need some effort to 
work with ATM SVCs.

-rick

---

From: Todd Marshall <[email-masked]>
Date: Sat, 02 Aug 2003 19:22:23 -0500

> http://www.msci.magic.net/harp/harp2.html

It's now on my to-do list.

> limitation - it's built for ATM PVCs so it would need some effort to

There's little difference between PVC's and SVC's  in operation. It's 
all in the signaling to nail down the connection with the network 
elements. The strategies for PVCs are then about matching a data's QoS 
requirements to existing pipes already set up. This becomes a multilple 
call per connection model. That's how they got into the DiffServ and 
IntServ trap. I think this is silly. I favor a multiple connection per 
call model with SVCs making up the connections and the protocol closing 
all connections at once when you "hang-up" the call.

ATM initially only had PVCs. SVCs came along later. PVCs do have the 
advantage that when a network element goes down, it can automatically 
configure itself when it comes back up (i.e. it remembers its PVC 
settings). . However, this is also a disadvantage. Until it comes back 
up nothing works that was going through that node.

/Todd

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->