Minutes of  IP over VBI BOF 

Title:  IPVBI BOF
Date:  12/8/97
Chair: Dan Zigmond
Reported by: Don Newell

Summary of meeting:

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 disucssion 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 concensus 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.

Presentation Details:

Dan Zigmond started the discussion with a recap of the Munich meeting.
He indicated that the mailing list 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 discusssion 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 architecural 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
encourgement 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