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:
· Ruston Panabaker from Microsoft gave an overview of his draft proposal "The Transmission Of IP Over The Vertical Blanking Interval Of A Television", targeted towards the NTSC/NABTS world.
· Simon Wegriff from Phillips presented an IP over the PAL VBI with WTS proposal, and describing what would need to change in Ruston's proposal to make it useful in his environment.
· Jim Carruthers, from NORPAK, talked about FEC issues and the desireability of having one FEC for all environments.
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.
· IP over VBI opportunity (VBI everywhere, non-obtrusive, always-on)
· NTSC Opportunity (10 Possible VBI lines for IP multicast, full screen gets more)
· Design goals (use existing standards e.g. multicast IP, FEC) Make layering clean.
· His stack NTSC VBI > NABTS with FEC > SLIP-like framing > IP > UDP > Apps
· Gave some explanation of his compression scheme
· NABTS 1 packet per scan line of video (shows each field) 26 bytes of useful data per scan line
· 16 packets by 28 bytes is a bundle. Talked about the FEC calculation across data bundles and explained
· How it works. Stated that data should be passed up even when FEC bad and data cannot be repaired. CRC will catch any bad data at a higher layer. This lets good data which is useable be picked up by
· Layers higher up the stack.
· Can send uncompressed and compressed headers and described unidirectional header compression (schemas etc) table lookup.
· Talked about why IP over VBI is useful from app and convergence level
Simon Wegrif presented IP over PAL:
Saw same opportunities as MS talked about. Saw IP as important data type.
· Presented his proposal as an evolution of MS draft from Panabaker.
· Compatible with ETS specifications for data transmission. Care is taken so it won't interfere with existing services.
· Stack is PAL VBI > WST with FEC > SLIP > IP.
· PAL VBI has more bytes available than NTSC, tried to take advantage of the extra bytes for larger payload.
· He described some of the packet structure differences.
· FEC is somewhat different than NORPAK and M.S.
· Briefly touched on IP over PAL addressing issues.
· Questioned if IP compression suited to this environment.
· The claim is this proposal is compatible with European broadcaster environment and then talks more about advantages and convergence.
Jim Carruthers gave a brief discussion about NORPAK and FEC
· Gave some NORPAK history., Developer of packet data broadcast concepts in this environment.
· Around the world there are something like 15 TV systems with combinations of color bandwidths etc. NABTS is used in all these systems, WST is used in 625 line systems.
· Data Standards history overview.
· NORPAK proposal is to merge two drafts by Simon and Ruston allowing both NABTS and WST to be comprehended.
· NORPAK FEC proposed as the standard FEC mechanism for all IP over VBI.
Discussion
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:
· FEC
· Addressing
· Framing
· Interleaving
None Received