Re: [FECFRAME-PROTO] SDP params for FEC

Marshall Eubanks <tme@multicasttech.com> Wed, 26 September 2007 16:52 UTC

Return-path: <fecframe-proto-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa7L-0007QB-3w; Wed, 26 Sep 2007 12:52:07 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa7K-0007PK-En for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:52:06 -0400
Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaa7J-0005RG-6Z for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:52:06 -0400
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 8472226; Wed, 26 Sep 2007 12:52:04 -0400
In-Reply-To: <38c19b540709260937p28e70f11x13113470ccb227d0@mail.gmail.com>
References: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> <C30B1BCD.1C8E3%mark@digitalfountain.com> <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> <38c19b540709260937p28e70f11x13113470ccb227d0@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <2394A33F-0DF7-4DFB-AE22-C28240889F94@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks <tme@multicasttech.com>
Subject: Re: [FECFRAME-PROTO] SDP params for FEC
Date: Wed, 26 Sep 2007 12:52:00 -0400
To: Greg Shepherd <gjshep@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306
Cc: fecframe-proto@ietf.org
X-BeenThere: fecframe-proto@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Fecframe protocol design team <fecframe-proto.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/fecframe-proto>
List-Post: <mailto:fecframe-proto@ietf.org>
List-Help: <mailto:fecframe-proto-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=subscribe>
Errors-To: fecframe-proto-bounces@ietf.org

On Sep 26, 2007, at 12:37 PM, Greg Shepherd wrote:

> On 9/22/07, Ali Begen (abegen) <abegen@cisco.com> 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. :(

Hopefully today, Greg

>
> Greg
>
>> Any thoughts?
>>
>> -acbegen
>>
>>
>>
>>> -----Original Message-----
>>> From: Mark Watson [mailto:mark@digitalfountain.com]
>>> Sent: Monday, September 10, 2007 4:06 PM
>>> To: Ali Begen (abegen); fecframe-proto@ietf.org
>>> 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)" <abegen@cisco.com> 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:gjshep@gmail.com]
>>>>> Sent: Sunday, September 02, 2007 7:03 PM
>>>>> To: Michael Bany
>>>>> Cc: Ali Begen (abegen); Ulas Kozat; Marshall Eubanks; Mark Pullen;
>>>>> fecframe-proto@ietf.org; 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 <mbany@dvblink.net> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Do we have any kind of simple agenda?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Ali Begen (abegen) [mailto:abegen@cisco.com]
>>>>>>  Sent: Friday, August 31, 2007 6:39 PM
>>>>>>  To: Michael Bany; Ulas Kozat; Marshall Eubanks
>>>>>>
>>>>>>  Cc: Shiloh Dorgan; Mark Pullen; fecframe-proto@ietf.org
>>>>>>  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:mbany@dvblink.net]
>>>>>>  Sent: Thursday, August 30, 2007 5:01 PM
>>>>>>  To: Ulas Kozat; Marshall Eubanks
>>>>>>  Cc: Shiloh Dorgan; Mark Pullen; fecframe-proto@ietf.org
>>>>>>  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:ulas.kozat@gmail.com]
>>>>>>  Sent: Thursday, August 30, 2007 6:59 PM
>>>>>>  To: Marshall Eubanks
>>>>>>  Cc: Shiloh Dorgan; Mark Pullen; fecframe-proto@ietf.org
>>>>>>  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 <tme@multicasttech.com> 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
>>>>>>  FECFRAME-PROTO@ietf.org
>>>>>>  https://www1.ietf.org/mailman/listinfo/fecframe-proto
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> FECFRAME-PROTO mailing list
>>>>>> FECFRAME-PROTO@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> FECFRAME-PROTO mailing list
>>>> FECFRAME-PROTO@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto
>>>
>>
>> _______________________________________________
>> FECFRAME-PROTO mailing list
>> FECFRAME-PROTO@ietf.org
>> https://www1.ietf.org/mailman/listinfo/fecframe-proto
>>
>
> _______________________________________________
> FECFRAME-PROTO mailing list
> FECFRAME-PROTO@ietf.org
> https://www1.ietf.org/mailman/listinfo/fecframe-proto


_______________________________________________
FECFRAME-PROTO mailing list
FECFRAME-PROTO@ietf.org
https://www1.ietf.org/mailman/listinfo/fecframe-proto