Four Bars

By Ivan Gevirtz

created: Tuesday, May 22, 2007
updated: Monday, January 07, 2008

The cellular phone industry has gravitated towards the 4 bar metaphor for representing radio signal strength of a given phone at a given time and location.  This metaphor is very easy to understand, and represents information a user can act upon; If the user has too few bars, she can move to a place which has better signal strength.  However, there is a critical shortcoming in the 4 bars metaphor as currently deployed by the cellular industry.  The shortcoming is that the bars do not realistically represent what the user ultimately cares about -- the voice quality of the call.

The 4 bars metaphor should be changed to actually represent the user experience.  In today's world, too few bars usually means poor call quality, but a full 4 bars may still result in poor voice quality.  Today's peer to peer communication applications, such as VOIP and video, have a similar problem.  I may be "online" and know that so is my friend.  However, we may be unable to make an Internet call to the other person, and if we do, the call quality may be poor.

There are a myriad of factors which could influence the call quality.  While there will always be a dynamic component to call quality, especially with moving endpoints, the potential can be measured and presented to the user in a familiar format: Four Bars.  For example, each user in your buddy list could have the familiar 4 bars graph next to their name representing the end-to-end network path characteristics.  For a video application, 4 bars might mean low latency, high quality video.  3 bars might mean somewhat lower quality video, or perhaps the occasional video glitch.  2 bars might mean small, choppy video, and 1 bar might mean only voice is possible.

We can extend the Four Bars metaphor beyond simply end-to-end connection quality.  It could also represent communication capabilities.  For example, if the connection is sufficient, we can "light" the video call icon.  We can also "light" the voice icon, and the IM icon.  If the person has made their cell phone number accessible to us, we can also highlight the SMS button.  This would represent a significant jump in utility over the current binary standard most IP based communication products use: Online or Offline.  This "extended presence" would have a dynamic quality, and could change over time.  A user's network may become congested, or a user may be in the office and decide to only offer voice calling and IM.

There are several technical hurdles which must be addressed to make a 4 bars scheme practical and useful.  I will expose and address them via use-case based scenarios.

  1. User comes online.  He sees his buddy list and instantly knows who is online.  His buddy list begins to display bars next to his other buddies who are online.  As his list gets updated, each buddy also gets the same number of bars displayed next to his name.
  2. User comes online, and has a buddy on his list who does not list him as a buddy.
  3. User is online, and one of his buddies on his buddy list comes online.  The users buddy has the user on his buddy list as well.
  4. User is online, and one of his buddies on his buddy list comes online.  However, the user is not on his buddy's list.
  5. User wants to test connection quality to a named, non buddy list, endpoint, or a non-buddy list user wants to test a connection with us.

Determination of when to test each pair is one of the key challenges.  Only one pair can be tested at a time, and the endpoints may not be in a call during testing.

Scenarios 1-3

The first three scenarios are addressed by having the user who just came online manage contention for connection quality testing.  Since part of this process involves peer to peer connection establishment, a publicly accessible server must be used to relay the requests.  This server may be the presence server.

The online user sends out test request messages (via the server) to each buddy in his buddy list.  This request contains the time differential from current.  When the buddy gets this message, the 4 bars show even dashes [----] indicating that the connection test is pending.  If the buddy is not in a call, and does not have a connection test scheduled, it sends back an ACK with the requested time.  If the buddy is in a call, or that time slot is unavailable, it sends back a NAK with a new time.  The new time may be 0 if the buddy is in a call.  This process continues until one side can agree on the time delta proposed by the other side.  Once the new time is good, the user sends out an ACK with the time.  The buddy mirrors this ACK and the test is scheduled.

Order of testing can be controlled by the user who just came online, and can be negotiated via ACK/NAK mechanism.

Scenario 4

In this scenario, after the user's buddy comes online, the client will not get a connection test request from the recently online buddy.  The user's client can thus decide to initiate a test request with the buddy.  Then this becomes the same as scenario 5, below.

Scenario 5

In this scenario, an unknown user is involved.  The request and acknowledgement procedures are the same, but only if the requested peer decides to participate.  This may be a setting on the client, or may be a user prompt.  The client setting could be automatically determined, for example, be based on local bandwidth or CPU utilization.

Connection Testing

Connection testing has two phases.  The first is testing the establishment of a peer to peer connection.  Can a connection be made?  If so, then sending a brief stream of simulated media and measuring what arrives can help determine latency and packet loss characteristics, and is sufficient for a simple 4 bars measurement.

If the connection establishment can not be made, further, periodic attempts may be tried.   These attempts may use the same heuristic, or may vary it to see if there are other parameters which will allow the connection to be made.  These additional attempts should be widely spaced in time, to allow router tables to reset.  Until a connection can be established, 0 bars should be reported.

Connection Testing with CRUSH

CRUSH enabled peers may have two stages of calls -- the relayed stage and the peer to peer stage.  Relay is expensive, and operators may want to limit relayed calls to 2 or even 1 bar.  Which connection (relay or p2p) is tested and displayed by 4 bars depends on the parameters of the network, and can be selected by the operator.  Generally, the best free connection is what the user wants, and is what should be displayed.

Interestingly enough, information gathered during connection testing can be used by CRUSH to make future connection establishment faster and more reliable.  Hints about endpoints characteristics and connection establishment requirements can be stored for future use.

8 Bars?

4 bars each for peer to peer and for relay connections.  Do you want to pay more for more bars?  Does your peer?  You could even to a CRUSH style handoff if another (new) path allows for more bars.  Perhaps the relay server can transcode your codecs to result in high quality video for both, but you have to pay for the service...

 

 

===================================================================

The original article (from 4/28/2006)

===================================================================

Four Bars

There's some question as to what our various firewall colors should represent. In reality, what we do now does NOT address the salient question: Will the call go through?

We can do better. I think a long term solution may be to set up a server on the public Internet. When we do our test, we end with trying to connect to that server, VIA making a CVP call to that server. That server is set to auto answer, and to send a pre-recorded "SUCCESS/welcome" video clip as a result if it gets both audio and video from the other end.

That answers the question if the client can ever expect to be able to make a call. If that fails, then it is a certain RED light. It may succeed and other calls may fail, but at that point we'll know that some calls are able to succeed.

So, we have a realistic RED/GREEN test for firewall traversal.  But, CVP is a peer to peer application, and calls to one user may work while calls to another may not. How do we represent this?  I really like the "signal strength" metaphor adopted from the cell phone industry. For example, "Four Bars" means that the call will go through, the latency and jitter isn't too bad, and firewall traversal is not a problem. Three bars means something somewhat less -- Call connect time may be longer, for example.  Two Bars means that you may not always be able to connect, or that the video quality may be poor (i.e.. network congestion)  One or No bars mean that you may not be able to connect at all, and if you do it may be audio only.

We could put these bars in the UI on a PER BUDDY basis. In other words, EACH buddy we see on the list gets a bar rating. Perhaps we add in an auto-answer "reflector" to the client so we can actually test the connectivity between the endpoints to determine the bar ratings. In other words, we do a fake call to each online buddy, and use the results to set the bar level. This may be expensive (bandwidth, etc...), so maybe we only do it at the beginning, and then just ping that user to make sure that info is the same...  These pings could be used to determine if latency or jitter has changed, not only if you could connect.

Whaddya think? Is my signal at 4 bars?

===================================================================

Firewall Diagnostic Test and Bug 1751

A few thoughts on the Firewall Diagnostic Test and Bug 1751.  I saw some screen shots from Ira where an install and setup wizard had the user run the firewall test. Yesterday. Ira and I discussed the meaning of the colors, and the results were that even in the case of a Red light, it is worth trying to make the call. It is possible you can't get to one address server (STUN or DUDP) yet you still CAN connect.

As such, I think having users run the test is currently gratuitous.  Worse, I think it actually has a negative effect on the users experience by inducing unneeded anxiety. Even for those who get a green light, it makes the product more complicated and thus more scary. And, worse, there is nothing they can do about the test results. Rather, I think we should offer firewall diagnostics upon call connection failure. If it doesn't work, then offer them relief for the problem, rather than have them worry about a non existent problem.

Which brings me to my next point, and a possible solution for part of bug 1751 (the Netgear WRG614 part). I think we should have an "Advanced Firewall Settings" somewhere where the user can tweak the settings based on the firewall diagnostics test.

Here's what I mean. We could continue down the path of having our software automatically have the smarts to traverse all firewalls.  But, pre-CRUSH, that leads to another usability problem -- the traversal heuristic will take longer, and thus delay call setup time. Eventually we could feed in the Firewall Diagnostic results to tweak how we do our traversals, but I'd recommend that now we provide capability to tweak the settings manually. The settings would be what addresses we try to connect via:

  1. Use Internal address and port
  2. Use External address and identity port
  3. Use External address and mapped port
  4. Use External address and Shotgun around mapped port
  5. Use UPnP port mapping

The user should be able to turn each of these settings on and off.  If we turned off #2 above, I think we may solve the problem in bug 1751 for the Netgear firewall. (needs to be tested, but a hunch).

Once we have CRUSH, call setup time is not an issue (setup via a relay server should be quick!) and we can do all this automatically, and perhaps upon success store the settings to help with future calls.

What do you think?