Re: [FECFRAME-PROTO] SDP params for FEC

["Greg Shepherd" <[e-mail]>]

On 9/22/07, Ali Begen (abegen) <[e-mail]> wrote:
> Hi everyone,
>
> Regarding the SDP signaling for FEC, I have something missing in my
> notes. As far as I remember, we mainly discussed the offer/answer model
> for our framework. That is, we said that the sender could offer multiple
> (nested or not) FEC flows (each probably with different levels of
> protection, latency budgets, priority, etc) from which the receiver(s)
> can select and join the corresponding multicast group to receive the
> repair packets.
>
> However, this offer/answer model does not let the receiver ask for a
> particular FEC scheme from the sender. Does it? This can be particularly
> useful in unicast applications (or even in multicast when there is a
> middle box that manages the sender on behalf of the receivers),

...or just the FEC stream on behalf of the sender.

> where
> the receiver should be able to ask from the sender whatever FEC it wants
> to receive or the receiver can let the sender know how much buffering it
> can tolerate. Remember the min_buffer_time attribute? The receiver
> should also be able to set this ...

For the above condition in which the FEC stream is not coming from the
same source as the source data, the initial SDP file should specify
the FEC request address for just such a handshake IF this is an
available option. From there the interaction is in the protocol.

> Can we do this by using the same FEC Framework Configuration Information
> and FEC-Scheme-Specific Information that we use for the offer/answer
> model? What is the best way to execute this "on-demand" model?

Sorry if I'm stating the obvious but I lack the clarity of any notes
from the meeting. :(

Greg

> Any thoughts?
>
> -acbegen
>
>
>
> > -----Original Message-----
> > From: Mark Watson [mailto:[e-mail]]
> > Sent: Monday, September 10, 2007 4:06 PM
> > To: Ali Begen (abegen); [e-mail]
> > Subject: Re: [FECFRAME-PROTO] SDP params for FEC
> >
> > Ali,
> >
> > I agree. This is an important topic for next week.
> >
> > The current fecframe draft envisages an approach similar to
> > that taken by the FEC Building Block in RMT. In this approach
> > we would define 'containers'
> > for FEC-scheme-specific information, with the intention that
> > each FEC Scheme will define exactly the information it needs
> > and how it should be coded into the container.
> >
> > Content delivery protocols can then define mechanisms for
> > carrying these 'containers' in a way which is independent of
> > the FEC Scheme used.
> >
> > So, the first task is for us to identify which information is
> > 'FEC Scheme independent', for which we must define specific
> > protocol elements. This includes at least the identity of the
> > FEC Scheme. Then we can define a container for the
> > FEC-Scheme-specific information. In RMT, both kinds of
> > information are referred to as FEC Object Transmission Information.
> >
> > FYI, in DVB they have their own XML-based 'Service Discovery
> > and Selection'
> > scheme which is used to advertise services and communicate
> > the information needed to access the service (e.g. Multicast
> > address). The FEC information is carried here too. DVB also
> > defines RTSP headers to negotiate this information.
> >
> > ...Mark
> >
> >
> > On 9/10/07 3:18 PM, "Ali Begen (abegen)" <[e-mail]> wrote:
> >
> > > Hi everyone,
> > >
> > > One topic that I believe we need to discuss is the definition of
> > > FEC-related parameters within SDP. That is, we need to
> > identify what
> > > kind of FEC parameters need to be conveyed through SDP between the
> > > receiver(s) and sender(s) so that the senders generate the
> > right FEC
> > > and the receivers know what they receive. Possible
> > parameters are the
> > > session identifiers, protection period, block size, FEC
> > coding scheme,
> > > FEC type, annex type (sending arrangements), etc.
> > >
> > > Some parameters are algorithm-specific (e.g., L and D
> > values for CoP3
> > > and the seed information for Raptor). We may need these as well,
> > > however, we should have the right amount of abstraction.
> > >
> > > As far as I know, there is not much about this in the current IETF
> > > documents. DVB is pushing for the hybrid FEC (CoP3 +
> > Raptor), however,
> > > I am not sure what is proposed to negogiate the algorithm-specific
> > > parameters between the receiver and sender. RFC 4756 is not
> > much help
> > > from this perspective, either.
> > >
> > > I am hoping we can make a progress in this front and will
> > have a draft
> > > for the December meeting.
> > >
> > > BTW, this work may require a joint collaboration between
> > FECframe and
> > > MMUSIC as well as AVT WGs.
> > >
> > > Ali
> > >
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Greg Shepherd [mailto:[e-mail]]
> > >> Sent: Sunday, September 02, 2007 7:03 PM
> > >> To: Michael Bany
> > >> Cc: Ali Begen (abegen); Ulas Kozat; Marshall Eubanks; Mark Pullen;
> > >> [e-mail]; Shiloh Dorgan
> > >> Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting
> > in Fairfax
> > >>
> > >> Yes, a bit.. Sorry I haven't sent something out before but
> > I've been
> > >> on the road the past week and still have more road ahead.
> > >>
> > >> What we need first is for someone to volunteer to outline
> > the current
> > >> relevant work from the other groups, ie RMT
> > >>
> > >> Mark is the primary keeper of our requirements draft so we need
> > >> confirmation that he will be able to make the interim meeting.
> > >>
> > >> Then with the requirements and an understanding of the current
> > >> relevant work we can begin to address what extensions are
> > necessary
> > >> to meet our goals of FECFrame.
> > >>
> > >> So who is willing and able to provide the outline of
> > current relevant
> > >> work?
> > >>
> > >> Thanks,
> > >> Greg
> > >>
> > >> On 9/2/07, Michael Bany <[e-mail]> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Do we have any kind of simple agenda?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> From: Ali Begen (abegen) [mailto:[e-mail]]
> > >>>  Sent: Friday, August 31, 2007 6:39 PM
> > >>>  To: Michael Bany; Ulas Kozat; Marshall Eubanks
> > >>>
> > >>>  Cc: Shiloh Dorgan; Mark Pullen; [e-mail]
> > >>>  Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting
> > >> in Fairfax
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> I will be driving from RTP on Saturday. So, I can join a
> > dinner on
> > >>> Sunday if anybody interested. I'll leave at 8pm on 18th
> > out of DCA.
> > >>> And, we can start at 9am on both days.
> > >>>
> > >>>
> > >>>
> > >>> You all have a nice long weekend.
> > >>>
> > >>>
> > >>>
> > >>> - Ali
> > >>>
> > >>>
> > >>>
> > >>>  ________________________________
> > >>>
> > >>>
> > >>> From: Michael Bany [mailto:[e-mail]]
> > >>>  Sent: Thursday, August 30, 2007 5:01 PM
> > >>>  To: Ulas Kozat; Marshall Eubanks
> > >>>  Cc: Shiloh Dorgan; Mark Pullen; [e-mail]
> > >>>  Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting
> > >> in Fairfax
> > >>>
> > >>> I will be arriving late night Sunday and depart out of
> > >> Reagan National
> > >>> at 5:30 pm on the 18th of September.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> From: Ulas Kozat [mailto:[e-mail]]
> > >>>  Sent: Thursday, August 30, 2007 6:59 PM
> > >>>  To: Marshall Eubanks
> > >>>  Cc: Shiloh Dorgan; Mark Pullen; [e-mail]
> > >>>  Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting
> > >> in Fairfax
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>  Greetings--
> > >>>
> > >>>  I will be arriving late night Sunday and return back on 18th (my
> > >>> reserved flight leaves at 4:45pm from Reagan National).
> > >>>
> > >>>  Do we have a tentative schedule/agenda? If the meetings
> > >> will continue
> > >>> until late evening on 18th, I might change my schedule.
> > >>>
> > >>>  Ulas
> > >>>
> > >>>
> > >>> On 8/30/07, Marshall Eubanks <[e-mail]> wrote:
> > >>>
> > >>> OK, having waited for the dust to settle, and having polled the
> > >>> members who wanted the other  dates, the Design team
> > >> meeting will be
> > >>> at George  Mason University 17-18 September. Our thanks
> > to GMU for
> > >>> offering the  space.
> > >>>
> > >>>  Mark, Shiloh, can you recommend a nearby hotel ?
> > >>>
> > >>>  Also, we will need directions to the exact site of the meeting.
> > >>>
> > >>>  Travel arrangements :
> > >>>
> > >>>  Either Dulles (IAD) or National (DCA) airports have easy
> > >> access to
> > >>> GMU in Fairfax, Virginia.
> > >>>
> > >>>  National even has subway (Metro) access -
> > >>>
> > >>>  http://www.wmata.com/metrorail/systemmap.cfm
> > >>>
> > >>>  Blue line to the Orange line, Orange line to Vienna, a
> > >> short cab ride
> > >>> or CUE bus ride to GMU.
> > >>>
> > >>>  http://www.fairfaxva.gov/CUEBus/CUEBus.asp
> > >>>
> > >>>  I would allow at least an hour for this. A cab ride from
> > >> National or
> > >>> Dulles will cost order $ 30, maybe more from Dulles.
> > >>>
> > >>>  If anyone does not plan to have a car, please let me know.
> > >> I can pick
> > >>> up a limited number or people on the way in each morning.
> > >> Like many
> > >>> American suburbs, you will feel limited if you do not have
> > >> a car, but
> > >>> it is possible. The GMU campus itself is pretty spread out.
> > >>>
> > >>>  http://coyote.gmu.edu/map/fairfax.html
> > >>>
> > >>>  Baltimore Washington (BWI) is also possible but is a good
> > >> 1 and 1/2
> > >>> hour drive away at best and you have to go through or around
> > >>> Washington itself. I would not recommend it unless the
> > flights are
> > >>> really cheap.
> > >>>
> > >>>    Be warned that DC has a very strong and typical rush
> > >> "hour" (~6:30
> > >>> to 9:00 AM, ~4:00 to 7:00 PM). There will probably be
> > >> little traffic
> > >>> on Sunday.
> > >>>
> > >>>  If people come in early enough Sunday night we should
> > have dinner.
> > >>>
> > >>>  Regards
> > >>>  Marshall
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>  On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote:
> > >>>
> > >>>> Room 320 is reserved for the FECFRAME meeting 17-18 September.
> > >>>> Parking is $8/day. Let me know if anyone needs links for
> > >> directions
> > >>>> or has any questions.
> > >>>>
> > >>>> Shiloh
> > >>>>
> > >>>> Mark Pullen wrote:
> > >>>>> Marshall,
> > >>>>>
> > >>>>> I'm happy to sponsor the meeting 17-18 Sep, on one condition:
> > >>>>> I must be able to invite my students to listen in. Also
> > >> you should
> > >>>>> know that while the room will be provided at no cost, the  >>
> > >>> participants will need to pay ($7/day if it has not gone
> > >> up)  >> for
> > >>> parking. They should use the parking desk and pay there.
> > >>>>> The alternative is public transport- the Fairfax/GMU
> > >> CUE bus  >>
> > >>> provides an inexpensive shuttle to Vienna Metro and area
> > hotels  >>
> > >>> (see www.gmu.edu for info).
> > >>>>>
> > >>>>> Assuming the above is OK, I'm asking Shiloh to reserve
> > >> a room  >>
> > >>> for you (Shiloh, start with 320 ST2 if available).
> > >>>>>
> > >>>>> Mark
> > >>>>>
> > >>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote:
> > >>>>>
> > >>>>>> Dear Mark;
> > >>>>>>
> > >>>>>> I am trying to find a place for a design team meeting for the
> > >>>>>> Fecframe IETF working group.
> > >>>>>>
> > >>>>>> Fecframe is a new working group with a charter to  >>>  >>>
> > >>> ...develop specifications for using  >>> forward error correction
> > >>> (FEC) codes with applications in the  >>> Internet  >>>
> > to provide
> > >>> protection against packet loss. The group will develop a
> > >>>>> protocol
> > >>> framework for application of FEC codes to arbitrary packet
> > >>>>> flows
> > >>> over unreliable transport protocols over both IP
> > multicast and  >>>
> > >>> unicast.
> > >>>>>>
> > >>>>>> This has the potential to become an essential piece of
> > >> technology
> > >>>>>> underpinning IPTV.
> > >>>>>>
> > >>>>>> We need to have a meeting of the design team (6
> > >> people), and have
> > >>>>>> settled on the week of  >>> September 17th. We estimate
> > >> that this
> > >>> will require the use of a  >>> room for a day and a half,
> > >> but I would
> > >>>>>> like to secure a room for 2 days in total (9 to 5) in
> > >> case we run
> > >>>>>> long.
> > >>>>>>
> > >>>>>> At present, I think that everyone is available for the entire
> > >>>>>> week, and so room availability could determine  >>>
> > >> which two days
> > >>> we meet.
> > >>>>>>
> > >>>>>> Do you think that there is any chance we could meet at GMU ?
> > >>>>>> Basically, we would need a
> > >>>>>> conference room or classroom for 2 days. Let me know
> > >> what you think.
> > >>>>>>
> > >>>>>> Regards
> > >>>>>> Marshall
> > >>>>>>
> > >>>
> > >>>
> > >>>  _______________________________________________
> > >>>  FECFRAME-PROTO mailing list
> > >>>  [e-mail]
> > >>>  https://www1.ietf.org/mailman/listinfo/fecframe-proto
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> FECFRAME-PROTO mailing list
> > >>> [e-mail]
> > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto
> > >>>
> > >>>
> > >>
> > >
> > > _______________________________________________
> > > FECFRAME-PROTO mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/fecframe-proto
> >
>
> _______________________________________________
> FECFRAME-PROTO mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/fecframe-proto
>

_______________________________________________
FECFRAME-PROTO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/fecframe-proto