IP Video and Overhead

[George]

I'm actually sorta studying up on this whole IP video thing and one of the questions I have is how much overhead traffic is involved when sending video at say 384k.

For example I know that a call at 384k over IP doesn't look as good as a call at 384k over ISDN unless you're using H.264. This is because a good chunk of the bandwidth is taken up by IP headers and other signaling data.

Exactly how does this work and how much overhead are we talking about on a 384, 512, or 768 call?

[vtjoe]

for example I know that a call at 384k over IP doesn't look as good as a call at 384k over ISDN unless you're using H.264. This is because a good chunk of the bandwidth is taken up by IP headers and other signaling data.


What endpoints are you using? 384kbps for IP should look the same as 384kbps on ISDN (as long as you don't have packet loss). What also might make a difference is the audio encoder being used. For example, if G.722 (64kbps) is being used for ISDN and G.722.1 (24/32kbps) is being used for IP, G.722.1 will leave extra room for video.

General rule of thumb IP overhead = 1.2 x Video/Audio rate.

However, H.323 IP throttles - the bandwidth usually determines the top end for Audio & Video. The video sent will decrease with a lack of motion. The video on a 768 kbps call may throttle all the way down to 30kbps. The more efficient the encoder, the lower the bandwidth it will use and still maintain resolution and frame rate.

ISDN, on the other hand leaves the entire circuit up. Even though the H.261, H.263 or H.264 encoders are working the same by only sending changes, you still are paying for the full band.

Another thing to look at is that some manufactures measure bandwidth differently. Most endpoint products like Tandberg & Polycom determine bandwith with by measuring Audio+Video on ISDN or IP. However, the MGC Polycom/Accord does it differently by just looking at video over IP when a call is schedule - but looks at video AND audio over ISDN. Therefore a 384 kbps IP call over the Accord could really is a 384+64= 448kbps call.

ISDN also has "overhead" in the signalling, data (T.120) and far end camera control commands, but it is generally neglibible - with the possible exception of T.120. Also, ISDN has the D-channel with 3 x 16 kbps for a 384 kbps BRI-ISDN call.

[George]

vtjoe,

Thanks for the info on IP. I hadn't considered the different manufacturers thing and throttling.

On the ISDN side though, you mention T.120 but does anyone actually still use that? You also mentioned the D channel using 3x16 but the thing is that doesn't affect the call at all because an ISDN PRI carrys 23 B and a D just for that traffic. So when you bond 6X64Kbps B channels those channels are used for nothing but your video and audio data. So there is no loss.

[Entropy3XD]

George,

When refering to IP, you have to consider the bandwidth in both directions. In the world of IP, it is "simplex", meaning that on a 384k call you are sending out 384k and receiving back 384k, making the total bandwidth used actually more like 768k. You should figure in 20 percent for overhead.

[vtjoe]

On the ISDN side though, you mention T.120 but does anyone actually still use that?

I don't use it, but some people still do.

You also mentioned the D channel using 3x16 but the thing is that doesn't affect the call at all because an ISDN PRI carrys 23 B and a D just for that traffic. So when you bond 6X64Kbps B channels those channels are used for nothing but your video and audio data. So there is no loss.

You are correct.

[vtjoe]

Originally posted by Entropy3XD@May 21 2004, 12:05 PM
In the world of IP, it is "simplex", meaning that on a 384k call you are sending out 384k and receiving back 384k, making the total bandwidth used actually more like 768k.  You should figure in 20 percent for overhead.
Full duplex connection means you can send/receive at the same time - that is the transmit and recieve are on different wires. This is preferrable for VTC.

Half duplex environment means you have a shared media (the same wire or hub) for transmit and receive.

If you are using a 100 full duplex switched environment - then you can assume 384 kbps will max out at 1.2 x 384.

However, if you are in a 10/100 half duplex (hubs) environment, you will need to assume 384 really means 1.2 x 768.

And if you don't know, then you can convservatively assume you are in a hubbed environment. For videoconferencing, you want to stay away from hubs/half duplex situations.

For the bandwidth to your WAN or ISP connection, you can generally assume a full duplex situation regardless of hubs or switches on your LAN.

[Entropy3XD]

vtjoe,

Much better explanation. Thanks!

[Gary Miyakawa]

Also, lets not forget the "other" packeting overhead... If you are on xDSL you will have even more overhead for the ATM headers, etc.... Cable modem doesn't have this overhead (but has other "issues")...

Gary Miyakawa

[Entropy3XD]

Originally posted by vtjoe@May 28 2004, 09:07 AM
If you are using a 100 full duplex switched environment - then you can assume 384 kbps will max out at 1.2 x 384.

I do have one question. I you are using full duplex at 384k, aren't you transmitting out 384k (maximum) and receiving 384k (maximum) from the far end? If so, wouldn't your total bandwidth on the network be the total of the two plus overhead?

[robertk]

No,

If you have FULL duplex you transmit and recieve at the same time/rate.

Compare it to ISDN (wich is truly full duplex)
You don't say you have 128K channels... since they are full duplex 64K. (it's RX=TX not RX+TX :)

10Mbps etthernet (COAXIAL) uses the same cable for RX/TX. You can only do one thing on the cable at once, either send or recieve.

Evolution made them go away from the BUS topology and made it into a star-topology using hubs and RJ45 type of cabling, but still only half duplex.... and eventually they made 100MBps ethernet with full duplex.

I'm not sure about 10mbps full duplex if it ever existed. I was to belive that 10Mbps was limited to half duplex.

//Robert

[Entropy3XD]

Can anyone point to any docmentation on this? I have been looking around and am having a hard time finding anything that explains this in depth.

[robertk]

I found this while googling around...

http://www.experts-exchange.com/Networking/Q_20973732.html

//Robert
-------------------------------------------------------------------------------

Comment from mike1weaver
Date: 05/24/2004 09:32AM PDT

Comment

Gentleman,

Both of you are correct.
What is a full duplex Ethernet?

Full duplex means you can send and receive at the same time. This was impossible on coax, the original Ethernet media since it had only 1 conductor and Ethernet uses baseband signaling. However, 10BaseT and 100BaseT use a cable with 4 conductors. (Actually, there are typically 8 conductors but only 4 are used.) 1 pair of conductors is used to send data and the other to receive data. Each pair are also twisted around each other to help eliminate noise, hence the name unshielded twisted pair. With the right hardware you can theoretically double the speed of your network by sending and receiving simultaneously. Of course it?s a rare environment that has so much data to send in both directions but full duplex will give you a performance boost because you no longer have to wait for 1 host to finish sending before you start to send your data, i.e. a deferral

Exactly how does it work?
The original 10BaseT did not include full duplex but it did require something called a hub. The hub was simply a multiport repeater. Anything received on 1 port was sent out all the other ports. If two hosts (S and H) sent simultaneously there was a packet collision and this collision was sent out all the other ports. Collisions are normal events on an Ethernet ? don?t get me started. At some point someone figured out that it really wasn?t necessary for the hub to resend the packet out all its other ports, after all the destination was only connected to 1 port. The Ethernet switch is a multiport learning bridge. As packets come in on various ports it reads the packet header and determines the address of the sender. It then enters into a table the sender?s address and port number. An incoming packet is only sent out the port that the destination is connected to. Now when S and H send packets as long as they are going to R and G the switch can send both simultaneously. Of course if both S and H are sending to X one of the packets will have to wait in a buffer somewhere in the switch. Also, it?s still possible to get a collision or a deferral. If S sends to R and R simultaneously sends to H both R and the switch port connected to R will see a collision. If S starts sending early enough R will have to wait (defer) until S is done sending.

Full duplex is a way of eliminating collisions and deferrals. Simply put it turns off the collision detection hardware so that the network interface can transmit and send simultaneously, there can be no collisions or deferrals. So how can using full duplex reduce thruput and cause connections to fail?

Unless both sides of the connection, i.e. the network interface card and the switch port are configured for full duplex there will be a huge increase in the number of errors seen by the full duplex interface. In addition, packets that the full duplex interface thought that it sent will be dropped by the other side. They will need to be retransmitted when the TCP or application level fails to get an acknowledgment. What actually happens is this:
1)half duplex interface starts to send
2)full duplex interface starts to send
3)half duplex interface detects a collisions and basically stops sending since it stopped in the middle the packet is not valid
4)half duplex interface may also stop receiving the full duplex interface?s packet
5)full duplex interface sees the partial packet from the half duplex interface and flags an error
6)full duplex interface never gets an ACK for the packet that it sent and eventually retransmits it.

Later
Mike

[Gary Miyakawa]

Originally posted by Entropy3XD@May 29 2004, 07:05 AM
Can anyone point to any docmentation on this? I have been looking around and am having a hard time finding anything that explains this in depth.
It's got the Polycom spin on it but Tim does a pretty good job in this White Paper (http://www.polycom.com/common/pw_item_show_doc/0,,1781,00%2Ben-USS_01DBC.pdf).

Gary Miyakawa

[George]

Perfect Gary. Just what I was looking for. Thanks.

[Scooter]

George we ran 4 ip sessions at once into a PLCM roll around at 384 audio was great (722) video was horribly blocky with artifacts. We disconned a 2 sessions and redialed at 768 and it was still not equivalent to a 384 ISDN. I can get you some numbers as soon as we get the sniffer readings.

[George]

Scooter,

Check out page 4 of that PDF doc that Gary posted.

Yeah it looks like our only issue is figuring out why 384K video on IP is noticeably inferior to 384k video over ISDN. Your tests appeared to show that there were only 6 to 7kb of overhead data (1kb for every 48kb or so)?

Anyone else have any input on this? Why is ou 384k IP video worse quality than our 384K ISDN? From what our local net engineers have explained to me, there are so many factors (latency/network usage/network segment alternating speeds) involved that you simply can't put a number on the overhead required for IP video, although it appears that Polycom did just that in their whitepaper that Gary linked to above.

Any input would be greatly appreciated.

[Skylark]

Is it worse? in my experience It's the same but there are diffrent ways companies define there bandwith in calls.

When some companies talk about 384K transfer they are refering to H323+overhead so that the signal is realy about 320K compared to an ISDN call.

So:
384K IP call = 384k conference signal + 20% overhead = 464K total

or it could be:
384K IP call = 320K conference signal + 20% overhead = 384k total