2.3.19 IP over VBI (ipvbi) BOF

Minutes of The IP over VBI (ipvbi) BOF

Chair: Dan Zigmond

Reported by: Don Newell

I. Summary

Dan Zigmond introduced the agenda (at bottom of minutes) and decided to put the charter discussion off till all the technical discussion had been heard. The following people presented discussion material:

The presentations above were followed by a lively technical discussion and a consensus by the people present that this was an appropriate area for an IETF Working Group.

Below is a more complete description of the presentations made by each of the speakers, followed by a summary of the technical discussions and questions raised during and after the presentations.

II. Presentation Details

Dan Zigmond started the discussion with a recap of the Munich meeting. He indicated that the mailing list is not active enough and asked for suggestions to make it more effective.

Ruston Panabaker gave his presentation on IP over VBI. His discussion was focused on the NTSC with NABTS world. He indicated that it didn't appear difficult to extend the draft to encompass PAL etc. The following bullet points cover the gist of his presentation.

Simon Wegrif presented IP over PAL:

Saw same opportunities as MS talked about. Saw IP as important data type.

Jim Carruthers gave a brief discussion about NORPAK and FEC


A lively discussion about IETF being the appropriate place for this work broke out. Questions included how far down in the stack should the work go. This didn't really get resolved, but there was something like agreement that the standard would have to reach down far enough to specify how you signal IP in the VBI data packets.

The question about what would be the exact charter was raised by a couple of people. No wordsmithing took place so this was hard to capture.

What should happen with the Draft once done? People warned there are lots of opinions which will be heard and this is not a rubber stamp kind of organization. People still agreed that this is the right place.

Somebody (didn't get the name) expressed concern that this scheme will have an impact on the overall addressing structure used by IP. How does this play with the rest of the Internet addressing world. Need an architectural overview (applicability) discussion of how this fits into the IP world. Where are all the IP addresses coming from? Remarked that both V4 and V6 need to be addressed.

Andrew Cohen, from IO Research, talked about needing to make sure any standard we adopted worked in Asia. IO Research supplies data broadcast equipment in Asia and Middleast. He gave some business background around the company. Gives a pitch for IP over VBI and to offer encouragement that it is worthwhile. However, he has some differences in opinion about SLIP and FEC etc. The message returned was that the working group will try to develop a standard that works around the world. If specific things are being missed that keep proposals from working in Asia, he should bring that up and try to get it corrected.

Simon says his FEC is Reed Solomon, NORPAK is not. (Didn't hear the answer with Andrew's proposal, though it seemed a Reed-Solomon). BOCOM also has an FEC which is widely used. A representative from BOCOM gave some criteria around efficiency, latency, overhead, bit error rate, etc. that drive a FEC. BOCOM says that their FEC doesn't quite fit into this framework, and won't be made public. Simon pointed out error correction needs to be appropriate for channel and app characteristics.

IP question around FEC is discussed. The gist is that the IETF will not consider an FEC which is not open. IO Research would like to allow evaluation before making theirs public. Discussion made this seem difficult to manage. Question is when algos for FEC would be published.

A brief discussion around using Van Jacobsen-style header compression (RFC1144). A lot of people seemed to think this was not entirely the right way to go. (This is an interpretation) Ruston said they aren't using RFC1144 exactly, but they've got it working and have good results. He also pointed out that one reason for both a CRC and FEC is in support of header compression. Somebody mentions other header compression schemes. This is identified as an area for discussion.

Areas which were identified as needing discussion include the following:


None Received

Attendees List

go to list

Previous PageNext Page