Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax

From: "Michael Bany" <[email-masked]>
Date: Sun, 2 Sep 2007 12:25:19 -0500

Do we have any kind of simple agenda?

From: Ali Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, August 31, 2007 6:39 PM
To: Michael Bany; Ulas Kozat; Marshall Eubanks
Cc: Shiloh Dorgan; Mark Pullen; [email-masked]
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:[email-masked]] 
	Sent: Thursday, August 30, 2007 5:01 PM
	To: Ulas Kozat; Marshall Eubanks
	Cc: Shiloh Dorgan; Mark Pullen; [email-masked]
	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:[email-masked]] 
	Sent: Thursday, August 30, 2007 6:59 PM
	To: Marshall Eubanks
	Cc: Shiloh Dorgan; Mark Pullen; [email-masked]
	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 <[email-masked]> 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
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/fecframe-proto

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

---

From: "Greg Shepherd" <[email-masked]>
Date: Sun, 2 Sep 2007 19:02:46 -0700

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 <[email-masked]> wrote:
> 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.
>
>
>
> I will be arriving late night Sunday and depart out of Reagan National at
> 5:30 pm on the 18th of September.
>
>
>
>
>  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
>
>
>  Mason University 17-18 September. Our thanks to GMU for offering the
>  space.
>
>  Either Dulles (IAD) or National (DCA) airports have easy access to
>  Blue line to the Orange line, Orange line to Vienna, a short cab ride
>  or CUE bus ride to GMU.
>
>  I would allow at least an hour for this. A cab ride from National or
>  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
>  Baltimore Washington (BWI) is also possible but is a good 1 and 1/2
>  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
>
>
>
>
>  > Parking is $8/day. Let me know if anyone needs links for directions
>  > or has any questions.
>  >
>  > Shiloh
>  >
>  > Mark Pullen wrote:
>  >> Marshall,
>  >>
>  >> I must be able to invite my students to listen in. Also you should
>  >> provides an inexpensive shuttle to Vienna Metro and area hotels
>  >>> I am trying to find a place for a design team meeting for the
>  >>> 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
>  >>> 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
>  >>> conference room or classroom for 2 days. Let me know what you think.
>  >>>
>  >>> Regards
>  >>> Marshall
>  >>>
>
>

---

From: Mark Watson <[email-masked]>
Date: Tue, 04 Sep 2007 15:43:25 -0700

All,

I will arrive Sunday evening (7pm at Dulles). My return flight is ~7pm
Tuesday.

Are there any hotel recommedations ? Are we all going to try and stay in the
same hotel ?

...Mark

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 10 Sep 2007 09:54:50 -0700

Marshall,

Same question - did we get a hotel recommendation?

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 10 Sep 2007 10:03:19 -0700

Here's the GMU visitor hotel list - Fairfax campus:

http://www.gmu.edu/welcome/hotel.html

Greg

---

From: "Ulas Kozat" <[email-masked]>
Date: Mon, 10 Sep 2007 10:05:04 -0700

FYI, I made reservation at

  HAMPTON INNS
  HAMPTON INN FAIRFAX
  10860 FAIRFAX BLVD         PHONE-703 385 2600

Ulas

On 9/10/07, Greg Shepherd <[email-masked]> wrote:
> Sunday if
> reserved
> continue until

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 10 Sep 2007 13:23:11 -0400

That's not bad either.

Marshall

On Sep 10, 2007, at 1:05 PM, Ulas Kozat wrote:

> On 9/10/07, Greg Shepherd <[email-masked]> wrote: On 9/4/07, Mark  
> Watson <[email-masked]> wrote:
> > All,
> >
> > >> From: Ali Begen (abegen) [mailto: [email-masked]]
> > >> From: Michael Bany [mailto: [email-masked]]
> > >> From: Ulas Kozat [mailto:[email-masked] ]

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Mon, 10 Sep 2007 15:18:50 -0700

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:[email-masked]] 
> Sent: Sunday, September 02, 2007 7:03 PM
> To: Michael Bany
> Cc: Ali Begen (abegen); Ulas Kozat; Marshall Eubanks; Mark 
> Pullen; [email-masked]; Shiloh Dorgan
> 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.
> 
> > Sunday if anybody interested. I'll leave at 8pm on 18th out of DCA. 
> > And, we can start at 9am on both days.
> >
> >
> >
> > I will be arriving late night Sunday and depart out of 
> Reagan National 
> > at 5:30 pm on the 18th of September.
> >
> >
> >
> >
> >  Do we have a tentative schedule/agenda? If the meetings 
> will continue 
> > until late evening on 18th, I might change my schedule.
> >
> >  Ulas
> >
> >
> > 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.
> >
> > >> 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  >> 
> >  >> Assuming the above is OK, I'm asking Shiloh to reserve 
> a room  >> 
> >  >>> 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.
> >  >>>
> > >>> 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  
> > >>> week, and so room availability could determine  >>> 
> which two days 
> > we meet.
> >  >>>

---

From: Mark Watson <[email-masked]>
Date: Mon, 10 Sep 2007 16:05:33 -0700

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

---

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 13 Sep 2007 10:25:19 -0700

Marshall,

Were do we gather on the GME campus?

Thanks,
Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 13 Sep 2007 10:33:50 -0700

> is carried here too. DVB also defines RTSP headers to negotiate this

One todo that arose in Prague was the need for an RFC/Draft Rosetta
Stone - at the minimum a list of related IETF documents from which we
may extend for the FecFrame proto work. As usual nobody has come
forward to create such a list.

The call is still out. :) Even if you simply send document titles to
this list I can compile the list of docs for reference next week.

I've asked Ali to give a quick overview of SDP issues to seed some
discussion. Other real-world requirement discussions are welcome and
encouraged.

Thanks,
Greg

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Sep 2007 13:53:55 -0400

> Were do we gather on the GME campus?

Here are the basic directions :

Directions to meeting location (Science & Technology II bldg, room 320):
Park in the Sandy Creek parking deck: http://coyote.gmu.edu/map/ 
maphtml/parkingdeck2.html
Walk across the road to the Science & Technology II bldg, it is  
within view from the parking deck: http://coyote.gmu.edu/map/maphtml/ 
st21.html
Elevator to the third floor, turn left, go to the end of the hall,  
turn right and on your right will be the conference room, room 320.

3 choices :

1.) At the room, at 9:00 AM
2.) At the student center food court (it's just what it sounds like)  
at, say, 8:30

http://coyote.gmu.edu/map/maphtml/gwjc1.html

Johnson Center:
Ground Floor: Mason's own Jazzman's Café and the Bistro are popular  
partners on the ground floor of the Johnson Center. Jazzman's  
features live music and cool jazz, signature pastries, salads,  
sandwiches, and the full range of coffee drinks and teas a la  
Seattle's Best, while the Bistro offers a wide variety of carefully  
prepared comfort foods and fantastic atmosphere.
The Center Court on the Main Level Boasts
Taco Bell
Burger King
Italian fare at La Vincita
Pan-Asian specialties at Charlie Chang's Kwai
Charleston Market
Sub sandwiches on fresh baked breads at the Sub Connection
Vegan and vegetarian foods at Fresh'n Lite
Healthful smoothies, decadent dairy, and cookies at Freshëns
Café with great coffees, local baked goods, and a New York-style deli  
counter at La Patisserie
All the best of Starbuck's, and the convenience of grab and go can be  
found at the Express
Third Floor: George's Restaurant features well-rounded hot and cold  
favorites, white linens, and flowers.

I would suggest the Jazzman's Cafe from all of this.

3.) We meet outside GMU at 8:00 for a proper breakfast. There are  
AFAIK no great breakfast places in Fairfax City, so
we might as well meet at the Marriot.

Regards
Marshall

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Sat, 22 Sep 2007 17:47:38 -0700

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), 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 ... 

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?

Any thoughts?

-acbegen

> From: Mark Watson [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 4:06 PM
> To: Ali Begen (abegen); [email-masked]
> Subject: Re: [FECFRAME-PROTO] SDP params for FEC
> 
> Ali,
> 
> 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 
> 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
> 
> 
> > receiver(s) and sender(s) so that the senders generate the 
> right FEC 
> > and the receivers know what they receive. Possible 
> parameters are the 
> > documents. DVB is pushing for the hybrid FEC (CoP3 + 
> Raptor), however, 
> > I am not sure what is proposed to negogiate the algorithm-specific 
> >> Cc: Ali Begen (abegen); Ulas Kozat; Marshall Eubanks; Mark Pullen; 
> >> [email-masked]; Shiloh Dorgan
> I've been 
> >> 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
> >> 
> hotels  >>

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Wed, 26 Sep 2007 09:13:17 -0700

Any more comments/prior experiences on how we should do the on-demand
model?

-acbegen 

> From: Rajiv Asati (rajiva) 
> Sent: Tuesday, September 25, 2007 5:23 AM
> To: Ali Begen (abegen); Mark Watson; [email-masked]
> Subject: RE: [FECFRAME-PROTO] SDP params for FEC
> 
> Hi Ali,
> 
> Please see inline,
> 
> Very good point. Sorry, I wasn't there at the meeting, but I 
> envision that the CDP would be able to provide this 
> interaction one way or another.
> 
> Cheers,
> Rajiv
> 
> > From: Ali Begen (abegen)
> > Sent: Saturday, September 22, 2007 8:48 PM
> > To: Mark Watson; [email-masked]
> > Subject: RE: [FECFRAME-PROTO] SDP params for FEC
> > 
> > Hi everyone,
> > 
> > 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.
> > 
> > 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), 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 ...
> > 
> > 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?
> > 
> > Any thoughts?
> > 
> > -acbegen
> > 
> > 
> > 
> > > 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 
> 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.
> > > 
> > > 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
> > > 
> > >

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 26 Sep 2007 09:37:23 -0700

On 9/22/07, Ali Begen (abegen) <[email-masked]> wrote:
> middle box that manages the sender on behalf of the receivers),

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

> where

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.

> 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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 12:52:00 -0400

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

>> model
>> particularly
>> Information

Hopefully today, Greg

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Wed, 26 Sep 2007 09:54:37 -0700

> > receivers),

Yes, this is also a valid example.

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

By protocol you mean "SDP Negotiation" (which is still a draft, I
believe) or our framework?

-acbegen

> "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
> >
> >
> >
> > > >>>  I will be arriving late night Sunday and return back on 18th 
> > > >>> (my reserved flight leaves at 4:45pm from Reagan National).
> > > >>>

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 13:28:39 -0400

In Line

>>> attribute? The receiver should also be able to set this ...

Do we want  no handshake, a 2 way or a 3 way handshake to do this ?

If the FEC Server provides a list of possible blind choices (join  
this multicast group for this redundancy level ...), then no  
handshake is needed, just a list from the server. (Or, if you prefer,  
this is a blind one way handshake.)

If the FEC Server provides a list of possible choices then a 2 way  
handshake is required. (The receiver receives a list, then sends its  
choice back.)

These two choices are very similar, except that in the second, the  
choice may not be produced if not requested.

If the receiver tells the FEC server what to do, then in general a 3  
way handshake is required.

Receiver asks for option foo
Server says option foo is not allowed.
Receiver asks for option bar.
Server provides option bar.

I believe that SIP allows for all of this in its feature negotiation  
or media negotiation, and will try and
research the mechanism and find the appropriate RFCs.

Regards
Marshall