From fecframe-proto-bounces@ietf.org Sun Sep 02 13:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRtCP-0006KJ-K8; Sun, 02 Sep 2007 13:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRtCO-0006Fr-5x for fecframe-proto@ietf.org; Sun, 02 Sep 2007 13:25:24 -0400 Received: from www.amesweb.com ([216.218.233.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRtCM-0004Sl-Eo for fecframe-proto@ietf.org; Sun, 02 Sep 2007 13:25:24 -0400 Received: from exchange.amesweb.com ([12.215.108.10]) by www.amesweb.com with esmtp (Exim 4.10) id 1IRtCN-00063a-00 for fecframe-proto@ietf.org; Sun, 02 Sep 2007 12:25:24 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 2 Sep 2007 12:25:19 -0500 Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405118653@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax thread-index: AcfrYdEWkfgX0TjRSNq66OsU9qjovgAABoYwADF4t/AAVxYOkA== References: <5F47A4B4-9ED1-4CCD-9A3E-AAB145209977@multicasttech.com><46CC1E5F.4090508@c4i.gmu.edu><9D139D6F-82C2-4CD3-9CD4-D4E7EAB2251B@multicasttech.com><241bc2150708301659h1e7d2432p3764b2be5dc3fb63@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5405118653@xmb-sjc-215.amer.cisco.com> From: "Michael Bany" To: "Ali Begen (abegen)" , "Ulas Kozat" , "Marshall Eubanks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 74c8c6a39062dbfd583931efcf641276 Cc: Mark Pullen , fecframe-proto@ietf.org, Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384397591==" Errors-To: fecframe-proto-bounces@ietf.org This is a multi-part message in MIME format. --===============0384397591== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ED86.3C70C67B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ED86.3C70C67B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do we have any kind of simple agenda? =20 From: Ali Begen (abegen) [mailto:abegen@cisco.com]=20 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 =20 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. =20 You all have a nice long weekend. =20 - Ali =20 ________________________________ From: Michael Bany [mailto:mbany@dvblink.net]=20 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. =20 From: Ulas Kozat [mailto:ulas.kozat@gmail.com]=20 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 =20 =09 Greetings-- =09 I will be arriving late night Sunday and return back on 18th (my reserved flight leaves at 4:45pm from Reagan National). =09 Do we have a tentative schedule/agenda? If the meetings will continue until late evening on 18th, I might change my schedule.=20 =09 Ulas On 8/30/07, Marshall Eubanks 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. =09 Mark, Shiloh, can you recommend a nearby hotel ? =09 Also, we will need directions to the exact site of the meeting. =09 Travel arrangements : =09 Either Dulles (IAD) or National (DCA) airports have easy access to=20 GMU in Fairfax, Virginia. =09 National even has subway (Metro) access - =09 http://www.wmata.com/metrorail/systemmap.cfm =09 Blue line to the Orange line, Orange line to Vienna, a short cab ride=20 or CUE bus ride to GMU. =09 http://www.fairfaxva.gov/CUEBus/CUEBus.asp =09 I would allow at least an hour for this. A cab ride from National or Dulles will cost order $ 30, maybe more from Dulles.=20 =09 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=20 it is possible. The GMU campus itself is pretty spread out. =09 http://coyote.gmu.edu/map/fairfax.html =09 Baltimore Washington (BWI) is also possible but is a good 1 and 1/2=20 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. =09 Be warned that DC has a very strong and typical rush "hour" (~6:30=20 to 9:00 AM, ~4:00 to 7:00 PM). There will probably be little traffic on Sunday. =09 If people come in early enough Sunday night we should have dinner. =09 Regards Marshall =09 =09 =09 =09 On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote:=20 =09 > 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:=20 >> 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=20 >> 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=20 >>> 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=20 >>> 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=20 >>> 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=20 >>> 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=20 >>> 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 >>> =09 =09 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org=20 https://www1.ietf.org/mailman/listinfo/fecframe-proto =20 ------_=_NextPart_001_01C7ED86.3C70C67B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.co= m/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://ww= w1.ietf.org/mailman/listinfo/fecframe-proto

 

------_=_NextPart_001_01C7ED86.3C70C67B-- --===============0384397591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto --===============0384397591==-- From fecframe-proto-bounces@ietf.org Sun Sep 02 22:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS1H9-0005hy-8W; Sun, 02 Sep 2007 22:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS1H7-0005ht-Hn for fecframe-proto@ietf.org; Sun, 02 Sep 2007 22:02:49 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS1H5-0005Hc-J0 for fecframe-proto@ietf.org; Sun, 02 Sep 2007 22:02:49 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2196425wah for ; Sun, 02 Sep 2007 19:02:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=awllWX997DN7c3vIyU8hrJv3zkwZzrEFobrhBLbCJvLxgv1EugPkvH5wknUpgD6an4Mfjk+k+xAy9sW01rswjizgDQ/r5rwCNdUeecr0BDw/n5pSIl7zLB5cBvD/+5VIo3UgtMvpLxCAp7Y1v7BJeN6UA5xL/RXTYq5jIVd4a5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ktSbrBVh2G3l/AbHQAAPLngXGDCKj/rHs4rLhCAypkhwMbK6jkP29Fhiws212V2GrQLH/UHB21LWx2XgGxYOhxdxrNyGg+PKTxfk5V4EprhrglIaCgPQqLcbOEtBj7W11pO1PjQZ+KzBwUkV11mThw/NCZWoW37r8dbcRKg44RY= Received: by 10.114.155.1 with SMTP id c1mr2655360wae.1188784966613; Sun, 02 Sep 2007 19:02:46 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Sun, 2 Sep 2007 19:02:46 -0700 (PDT) Message-ID: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> Date: Sun, 2 Sep 2007 19:02:46 -0700 From: "Greg Shepherd" To: "Michael Bany" Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5F47A4B4-9ED1-4CCD-9A3E-AAB145209977@multicasttech.com> <46CC1E5F.4090508@c4i.gmu.edu> <9D139D6F-82C2-4CD3-9CD4-D4E7EAB2251B@multicasttech.com> <241bc2150708301659h1e7d2432p3764b2be5dc3fb63@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5405118653@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Shiloh Dorgan , Mark Pullen , fecframe-proto@ietf.org X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org 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 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 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 From fecframe-proto-bounces@ietf.org Tue Sep 04 18:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISh7U-0006C0-KV; Tue, 04 Sep 2007 18:43:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISh7S-0006Bt-NZ for fecframe-proto@ietf.org; Tue, 04 Sep 2007 18:43:38 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISh7R-0007eM-L3 for fecframe-proto@ietf.org; Tue, 04 Sep 2007 18:43:38 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Sep 2007 22:44:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 04 Sep 2007 15:43:25 -0700 Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax From: Mark Watson To: Greg Shepherd , "mbany@dvblink.net" Message-ID: Thread-Topic: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax Thread-Index: AcftzrGSKKdpAdD/Qw+KBjp1kEWWtwBdk9TJ In-Reply-To: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Mark Pullen , fecframe-proto@ietf.org, Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org 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 On 9/2/07 7:02 PM, "Greg Shepherd" wrote: > 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 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 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 12:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlyR-00047X-6k; Mon, 10 Sep 2007 12:18:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlyQ-00046n-T2 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 12:18:54 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUlyP-0003UX-O2 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 12:18:54 -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 8422297 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 12:18:50 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Date: Mon, 10 Sep 2007 12:18:45 -0400 To: fecframe-proto@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Subject: [FECFRAME-PROTO] Fwd: RSVP today for our 9/17 event with NASA Administrator Mike Griffin X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I don't know if Design Team people would find this interesting, but =20 we could all go if you want. Regards Marshall Begin forwarded message: > From: "MIT Enterprise Forum of Washington DC/Baltimore" =20 > > Date: September 5, 2007 1:08:38 PM EDT > To: tme@multicasttech.com > Subject: RSVP today for our 9/17 event with NASA Administrator Mike =20= > Griffin > > ** RSVP Now for Monday 9/17/07, Entrepreneurship and the Frontier =20 > of Space: Featuring Mike Griffin, Lon Levin and Jeff Guzy > www.mitef.org > > The MIT Enterprise Forum of DC-Baltimore, in cooperation with the =20 > MIT Club of DC, > invites you to this first in an exciting 2007-08 roster of =20 > educational events and > networking opportunities. > > Are we seeing a new wave of startups - firms leveraging research =20 > and funding to > create emerging space-based capabilities? > > Find out Monday, September 17 by joining the region's =20 > entrepreneurs, investors and > technology experts for this special MITEF season kick-off featuring: > Mike Griffin, NASA Administrator > Lon Levin, Chief Strategic Officer of Transformational Space (t/=20 > Space) and Senior Advisor to Slacker, both space-based startups. =20 > Also co-founder of XM Radio. > Jeff Guzy, Aprize Satellite > DATE/TIME: Monday, September 17, 6:30- 8:30 p.m. (buffet and =20 > networking followed > by program) > LOCATION: George Mason University, 3401 North Fairfax Drive (Room =20 > 329 in > the =93Original Building=93), Arlington, VA. (Near Virginia = Square/GMU =20 > Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP Now at: www.mitef.org > > Also, check out these other MITEF events and opportunities: > > - 9/25/07 Talk to the Angels, a popular closed door roundtable for =20= > selected seed-stage companies - apply today to be considered for =20 > participation! > http://www.mitef.org. Application deadline September 14. > - 10/09/07 Biotech TechTransferLab Event (Open to all) featuring =20 > the Deputy Director of NIST > - 11/13/07 Energy StartupLab Event (Open to all) focusing on clean =20 > and alternative energy. Apply to be a presenter at www.mitef.org. > - 12/11/07 DC Discovery Event (Open to all) - An exciting new event > - 01/29/08 Annual MITEF Gala (Open to all) - Our yearly can't-miss =20 > event! > > Please forward this email to your friends and colleagues. > -------------------------------------------------------------------- > > More about the MIT Enterprise Forum's upcoming events... > > **9/17/07 - "Startups =46rom Space:" Entrepreneurship and the =20 > Frontier of Space with NASA Administrator Mike Griffin > > In the 1990s, entrepreneurs burst forth with new tech companies =20 > leveraging decades of > research and funding by government and industry. This became the =20 > dot-com era. Today, > some experts see a new wave of space startups emerging. > > These companies are leveraging research and funding to create new =20 > capabilities in the > areas of low-cost imagery, suborbital flights, geospatial =20 > positioning, low-cost microsats > and more. > > What are the opportunities for new terrestrial-focused, disruptive =20 > startups? Our special > guest panel will share their thoughts: > > - Mike Griffin, NASA Administrator: Mr. Griffin will talk about =20 > new space-based > capabilities and explore thoughts on how technology (like the =20 > Internet in the 1990s) can > enable a range of new firms to serve markets firmly grounded on =20 > earth. Having served as > COO for In-Q-Tel, Mr. Griffin brings perspectives from the space =20 > and entrepreneurial > communities. > > - Lon Levin, Chief Strategic Officer of Transformational Space (t/=20= > Space) and the > Senior Advisor to Slacker. Also co-founder of XM Radio. Mr. Levin =20 > will describe > how XM combined several emerging trends to create a family of =20 > satellite-based radio > stations. Lon will also share his predictions on where space-based =20= > capabilities will > create new disruptive firms. > > - Jeff Guzy, Aprize Satellite: Mr. Guzy will describe how low-cost =20= > microsatellites > carrying transponders can revolutionize a traditional industry - =20 > propane distribution - and > create 5x opportunities. > > - Moderator Al Mink, SRA International: Mr. Mink is Chairman of =20 > the MIT Enterprise > Forum DC-Baltimore chapter, an MIT graduate and co-author of the =20 > United States Air > Force's white paper on air and space integration. > > DATE/TIME: Monday, September 17, 6:30- 8:30 p.m. (buffet and =20 > networking followed > by program) > LOCATION: George Mason University, 3401 N. Fairfax Drive (Room 329 =20 > in the Original > Building, Arlington, VA (Near Virginia Square/GMU Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP: www.mitef.org > > Please note: For those regulars who know our regular meeting place, =20= > please be aware > that our kickoff program this year will held at George Mason =20 > University on a Monday. In > October, we will return to our regular meeting place at NRECA and =20 > our usual Tuesday > meeting time. > > ** 9/25/07 - Talk with the Angels, an educational diagnostic salon =20 > for seed-stage > ventures > > This popular MITEF event features a roundtable discussion format =20 > where selected seed- > stage startups are given the opportunity to briefly describe their =20 > ventures, then receive > feedback from a panel of angel investors and experienced executives. > > To facilitate sensitive discussions, the Forum must restrict =20 > audience attendance to > invitation only (presenters and panelists). Location (in Northern =20 > Virginia) and other details will be announced with invitations. > > Are you involved with a seed-stage company? Send us your =20 > application today: > http://www.mitef.org. Application deadline September 14. > > ** 10/09/07 - Biotech TechTransferLab, featuring the Deputy =20 > Director of NIST > > Join the Deputy Director of the National Institute of Standards and =20= > Technology (NIST) and > his team of scientists as they share the top six biotech-related =20 > technologies they've > spawned for commercialization. These technologies, such as =20 > microfluidics, enable nano- > level manipulation of materials. The Maryland Technology =20 > Development Corporation > (TEDCO) is a sponsor of MITEF Tech Transfer events. > > DATE/TIME: Tuesday, 10/09, 6:30- 8:30 p.m. (buffet and networking =20 > followed by > program) > LOCATION: NRECA, 4301 Wilson Blvd., Arlington, VA (by Ballston Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP (and check out our new, improved website!): www.mitef.org > > ** 11/13/07 - Energy StartupLab > > The Forum puts a spotlight on clean and alternative energy by =20 > showcasing two local high- > tech startups. Expert panelists share their insights and feelings =20 > about these firms and their > likelihood of becoming significant players on the energy scene. =20 > Stay tuned for more > details. > > The MITEF is seeking renewable energy and energy-related companies to > present. Go to www.mitef.org to apply. > > DATE/TIME: Tuesday, 11/13/07, 6:30- 8:30 p.m. (buffet and =20 > networking followed by > program) > LOCATION: NRECA, 4301 Wilson Blvd., Arlington, VA (by Ballston Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP (and check out our new, improved website!): www.mitef.org > > ** 12/11/07 - DC Discovery (a new MITEF event) > > The Forum screens candidate firms, coaches them and presents the =20 > two finalists before > you and a panel of experts. Don't miss this new, exciting Forum =20 > event. Stay tuned for > more details. > > DATE/TIME: Tuesday, 10/09, 6:30- 8:30 p.m. (buffet and networking =20 > followed by > program) > LOCATION: NRECA, 4301 Wilson Blvd., Arlington, VA (by Ballston Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP (and check out our new, improved website!): www.mitef.org > > ** 01/29/08 - Annual MITEF Gala > > At the annual, can't-miss Forum Gala, you'll see no black ties, but =20= > enjoy high-end food and > great entertainment. Past Forum presenters will relate their post-=20 > Forum experiences and > a well-placed technologist then will forecast technology trends for =20= > 2008. Stay tuned for > more details. > > DATE/TIME: Tuesday, 01/29, 6:30- 8:30 p.m. (buffet and networking =20 > followed by program) > LOCATION: NRECA, 4301 Wilson Blvd., Arlington, VA (by Ballston Metro) > COST: Open to the public. Free for MITEF members. $25* for non-members > RSVP (and check out our new, improved website!): www.mitef.org > > ----------------------------------------------------------------------=20= > -------- > * MIT Enterprise Forum membership is open to the public. > > The Forum is a nonprofit organization. A $75 annual membership =20 > provides free entrance > to most activities. Visit www.mitef.org to join. > > ----------------------------------------------------------------------=20= > ---------- > FORUM SPONSORS AND SUPPORTERS > Intwine > Morrison & Foerster > National Institute of Standards and Technology (NIST) > Ranablue > Shapiro Sher Guinot & Sandler > The Entrepreneur Center @ NVTC > Virginia CIT > > CELEBRATING OVER TWO DECADES > For over twenty years, the MIT Enterprise Forum of Washington, DC=97=20= > Baltimore > (www.mitef.org) has been the premier and longest established =20 > organization for promoting > entrepreneurship in the Washington/Baltimore area. It is open to =20 > all, both non-MIT and MIT- > associated, entrepreneurial-conscious individuals, including you! =20 > It is one of 23 worldwide > chapters of the MIT Enterprise Forum, Inc. Each year, Enterprise =20 > Forum headquarters > produces three newsletters full of information on Enterprise Forum =20 > programs, as well as > articles of interest to entrepreneurs and Enterprise Forum members. =20= > The latest issue is > now available online and can be found at http://=20 > enterpriseforum.mit.edu. > > The MITEF: "The Epicenter of The Entrepreneurial Ecosystem=94 > www.mitef.org > > =93MIT Enterprise Forum=AE" and =93Enterprise Forum=AE=94 are = registered =20 > trademarks of the MIT > Enterprise Forum, Inc. > > Note: To unsubscribe to this list, and remove your email completely =20= > from the MIT > Enterprise Forum database, please email the webmaster through our =20 > website at www.mitef.org. > > > You have received this message from the mailing list of MIT =20 > Enterprise Forum of Washington DC/Baltimore. > > If you would prefer not to receive these emails in the future, go =20 > to the opt-out page and press the 'Remove Me' button. _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Mon Sep 10 12:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmXG-0001z0-FJ; Mon, 10 Sep 2007 12:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmXF-0001yu-2P for fecframe-proto@ietf.org; Mon, 10 Sep 2007 12:54:53 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUmXD-00030p-Kk for fecframe-proto@ietf.org; Mon, 10 Sep 2007 12:54:53 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2366594wah for ; Mon, 10 Sep 2007 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BlWiZPTwWPCYFndP3LNYffOVFW+hUqeTzXL2oqXTW8Y=; b=pLaktpkiGnNWQZV/Vs90w5YLeyNBIYKAuXjseYsZBXGr1NyZUoAgvApybiB5cp3/wo0GxypcqNTGRVz/NA0bg2DvQhKQwEOcpt4HzPI1crxQiBued9QAMjwEbrHjfXLn7ZT8PIwRFteQ2XyLlXQrdtyWRVjI5v/aJNaY8VzRf/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f7Yg9twog27cpm6NbvzgVC+nbd0Y2Pml58zEMFdQ4V9QK6VmZjmsyQvS7sZcVsvk3jY3j+QE/w42nDxjkBiMaUvgHdUBn9pejZ2nQpT/wQTz897l6QsobKoSlh8Q0hdCqNmtnMFqdzZQ4UjxNUjXypXzmbySVNxq7m0wZvrlOPE= Received: by 10.115.92.2 with SMTP id u2mr4674053wal.1189443290293; Mon, 10 Sep 2007 09:54:50 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Mon, 10 Sep 2007 09:54:50 -0700 (PDT) Message-ID: <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> Date: Mon, 10 Sep 2007 09:54:50 -0700 From: "Greg Shepherd" To: "Mark Watson" Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: Mark Pullen , fecframe-proto@ietf.org, Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On 9/4/07, Mark Watson wrote: > 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 ? Marshall, Same question - did we get a hotel recommendation? Greg > ...Mark > > > On 9/2/07 7:02 PM, "Greg Shepherd" wrote: > > > 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 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 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 13:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmfX-0001DP-3G; Mon, 10 Sep 2007 13:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmfV-00010l-UC for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:03:25 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUmfU-0003Fw-2H for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:03:25 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2369497wah for ; Mon, 10 Sep 2007 10:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=egR+8KNxv6jq4hjcLXQkUCLYCZv7KXvA8eZ3FaWZkvQ=; b=tGTclbkggy/OJVQ8CDTYs+1j+cOAwq8pHIErsqNUpIECD+5nClggmnY9EbFI2ZIfc4xXJyerpbTVg8TMtGkzkyMH94VfTh6rAoB/tPm26OLrwlXk5qxEL4VUvsXienr4LtdDEhvaRDz11edWodLaYc0KNsPABoO/4wRa274TdHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eiiwY1TkuL3fdOtJkBqUdgH3g56P0PdLjpoPbM9RHMLSDfoVvUzBMj6pPv2adsZ4ztCfFKB4kD+OM0ODQfVlQokedctFkIEulhXz3BmzCPI21QAtCZzrRxS8kBb4ZWFhvFwYuEbppwEyCFVove9VSMcIqT3HQEmFUbcbSygK9bw= Received: by 10.114.166.1 with SMTP id o1mr4700172wae.1189443799713; Mon, 10 Sep 2007 10:03:19 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Mon, 10 Sep 2007 10:03:19 -0700 (PDT) Message-ID: <38c19b540709101003t2e1feb2erf2c7547e4ddc23ea@mail.gmail.com> Date: Mon, 10 Sep 2007 10:03:19 -0700 From: "Greg Shepherd" To: "Mark Watson" Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax In-Reply-To: <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: Mark Pullen , fecframe-proto@ietf.org, Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Here's the GMU visitor hotel list - Fairfax campus: http://www.gmu.edu/welcome/hotel.html Greg On 9/10/07, Greg Shepherd wrote: > On 9/4/07, Mark Watson wrote: > > 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 ? > > Marshall, > > Same question - did we get a hotel recommendation? > > Greg > > > ...Mark > > > > > > On 9/2/07 7:02 PM, "Greg Shepherd" wrote: > > > > > 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 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 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 13:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmh9-0004aF-OJ; Mon, 10 Sep 2007 13:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmh8-0004a9-Qi for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:05:06 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUmh7-0003IM-Bo for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:05:06 -0400 Received: by nz-out-0506.google.com with SMTP id n1so520192nzf for ; Mon, 10 Sep 2007 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=MhMvuU0KRBdrZFEWXgf6+00AEESzrrzZ0yZExSJjlzk=; b=COLlTYP3tFEmulXQnhUjQxgm0XqD/yW7GqrKWpdSyf5LQ6seMSZNCZMrKj9zoLHzEVFBGInVoPLimMlIluENVjGo1dr9fl47IK505JMCHaFOMaTWrE8v3aBOS4stKELNrfTN9EfUqv+HuGg0vlHk4Zz73CNtHAYzTPG8SaYYie8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B1q1Ih6zK/XoUxUOVRSYKnBdCT66krFdV8Ttg9zVF5fh+pKRR3KcuHHev5BojC3KF19LarxBL4m1sjC3MovWN1nNcz3uRJg5uKkFS5Ai6HAGQD3qUfPHCCVM3LQk9m9DYaN0nOHLYuTDWirlp5rpqK1xltCERumYZjLe6a7hq0I= Received: by 10.142.237.20 with SMTP id k20mr237788wfh.1189443904192; Mon, 10 Sep 2007 10:05:04 -0700 (PDT) Received: by 10.142.78.15 with HTTP; Mon, 10 Sep 2007 10:05:04 -0700 (PDT) Message-ID: <241bc2150709101005m51499e56qe6b46ab9a3e79111@mail.gmail.com> Date: Mon, 10 Sep 2007 10:05:04 -0700 From: "Ulas Kozat" To: "Greg Shepherd" Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax In-Reply-To: <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> MIME-Version: 1.0 References: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: fecframe-proto@ietf.org, Mark Pullen , Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0993085170==" Errors-To: fecframe-proto-bounces@ietf.org --===============0993085170== Content-Type: multipart/alternative; boundary="----=_Part_13841_13391572.1189443904182" ------=_Part_13841_13391572.1189443904182 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI, I made reservation at HAMPTON INNS HAMPTON INN FAIRFAX 10860 FAIRFAX BLVD PHONE-703 385 2600 Ulas On 9/10/07, Greg Shepherd wrote: > > On 9/4/07, Mark Watson wrote: > > 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 ? > > Marshall, > > Same question - did we get a hotel recommendation? > > Greg > > > ...Mark > > > > > > On 9/2/07 7:02 PM, "Greg Shepherd" wrote: > > > > > 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 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 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 > ------=_Part_13841_13391572.1189443904182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
FYI, I made reservation at

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

Ulas

On 9/10/07, Greg Shepherd <gjshep@gmail.com> wrote:
On 9/4/07, Mark Watson <mark@digitalfountain.com> wrote:
> 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 ?

Marshall,

Same question - did we get a hotel recommendation?

Greg

> ...Mark
>
>
> On 9/2/07 7:02 PM, "Greg Shepherd" <gjshep@gmail.com> wrote:
>
> > 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

------=_Part_13841_13391572.1189443904182-- --===============0993085170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto --===============0993085170==-- From fecframe-proto-bounces@ietf.org Mon Sep 10 13:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmxt-0001dB-AY; Mon, 10 Sep 2007 13:22:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmxs-0001ck-AR for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:22:24 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUmxr-0005SD-L8 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:22:24 -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 8422492 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:22:22 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) References: <46D6CB63.8010306@c4i.gmu.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Mon, 10 Sep 2007 13:22:17 -0400 To: fecframe-proto@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org OK, I have called the Stafford House Bed & Breakfast 3746 Chain Bridge Road Fairfax, VA 22030 to see if they have any room - they are the only one close enough to comfortably walk to GMU. I don't know if they are affordable, though. None of the others have the slightest bit of charm - I would recommend the Courtyard by Marriott - Fair Oaks 11220 Lee Jackson Hwy. Fairfax, VA 22030 It is easy to get to by car (just off I-66), and has bus ability too. Regards Marshall P.S. If any one wants to stay at Canary Cottage Bed & Breakfast ph: (703) 322-1811 8.0 miles from Fairfax Campus 7153 Main Street Clifton, VA 20124 let me know - I live in Clifton and can give you a ride. Begin forwarded message: > From: Shiloh Dorgan > Date: August 30, 2007 9:51:31 AM EDT > To: Marshall Eubanks > Cc: fecframe-proto@ietf.org, Mark Pullen > Subject: Re: FECFRAME Design Meeting in Fairfax > > Here are the details:: > > Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > > 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. > > Shiloh > > Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 13:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmyu-0002AP-57; Mon, 10 Sep 2007 13:23:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmyr-00027W-BG for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:23:25 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUmyq-0005US-Dp for fecframe-proto@ietf.org; Mon, 10 Sep 2007 13:23:25 -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 8422498; Mon, 10 Sep 2007 13:23:23 -0400 In-Reply-To: <241bc2150709101005m51499e56qe6b46ab9a3e79111@mail.gmail.com> References: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> <38c19b540709100954q1800c47fs1afc3be848e1e0cd@mail.gmail.com> <241bc2150709101005m51499e56qe6b46ab9a3e79111@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: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax Date: Mon, 10 Sep 2007 13:23:11 -0400 To: "Ulas Kozat" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: fecframe-proto@ietf.org, Mark Pullen , Shiloh Dorgan X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org That's not bad either. Marshall On Sep 10, 2007, at 1:05 PM, Ulas Kozat wrote: > > FYI, I made reservation at > > HAMPTON INNS > HAMPTON INN FAIRFAX > 10860 FAIRFAX BLVD PHONE-703 385 2600 > > Ulas > > On 9/10/07, Greg Shepherd wrote: On 9/4/07, Mark > Watson wrote: > > 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 ? > > Marshall, > > Same question - did we get a hotel recommendation? > > Greg > > > ...Mark > > > > > > On 9/2/07 7:02 PM, "Greg Shepherd" wrote: > > > > > 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 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 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 15:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpJF-0004YR-L4; Mon, 10 Sep 2007 15:52:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpJE-0004YL-I8 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 15:52:36 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUpJD-0003du-Qx for fecframe-proto@ietf.org; Mon, 10 Sep 2007 15:52:36 -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 8422862; Mon, 10 Sep 2007 15:52:34 -0400 In-Reply-To: References: <46D6CB63.8010306@c4i.gmu.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Mon, 10 Sep 2007 15:52:27 -0400 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > OK, I have called the > > Stafford House Bed & Breakfast > 3746 Chain Bridge Road > Fairfax, VA 22030 They have only 1 room available - a Suite with a King size bed. $ 159 for 1 person $ 179 for 2 (but you have to share the bed) Regards Marshall > > to see if they have any room - they are the only one close enough > to comfortably walk to GMU. I don't know if they are affordable, > though. > > None of the others have the slightest bit of charm - I would > recommend the > > Courtyard by Marriott - Fair Oaks > 11220 Lee Jackson Hwy. > Fairfax, VA 22030 > > It is easy to get to by car (just off I-66), and has bus ability too. > > Regards > Marshall > > P.S. If any one wants to stay at > Canary Cottage Bed & Breakfast > > ph: (703) 322-1811 > > 8.0 miles from Fairfax Campus > 7153 Main Street > Clifton, VA 20124 > > let me know - I live in Clifton and can give you a ride. > > > Begin forwarded message: > >> From: Shiloh Dorgan >> Date: August 30, 2007 9:51:31 AM EDT >> To: Marshall Eubanks >> Cc: fecframe-proto@ietf.org, Mark Pullen >> Subject: Re: FECFRAME Design Meeting in Fairfax >> >> Here are the details:: >> >> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >> >> 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. >> >> Shiloh >> >> Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Mon Sep 10 18:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUraq-0003Ho-1L; Mon, 10 Sep 2007 18:18:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrap-0003Hj-6R for fecframe-proto@ietf.org; Mon, 10 Sep 2007 18:18:55 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUrao-0007T2-1o for fecframe-proto@ietf.org; Mon, 10 Sep 2007 18:18:55 -0400 X-IronPort-AV: E=Sophos;i="4.20,233,1186383600"; d="scan'208";a="522387631" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Sep 2007 15:18:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8AMIrO3010283 for ; Mon, 10 Sep 2007 15:18:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AMIiFI018143 for ; Mon, 10 Sep 2007 22:18:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 15:18:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Sep 2007 15:18:50 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540709021902s2249062em2b6fa58e9178fd1f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP params for FEC thread-index: Acftzox5XqhdEoF6Sh2UTLCHdyT+PAGJ+5xw From: "Ali Begen \(abegen\)" To: X-OriginalArrivalTime: 10 Sep 2007 22:18:46.0838 (UTC) FILETIME=[8E4FC560:01C7F3F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9220; t=1189462733; x=1190326733; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20SDP=20params=20for=20FEC |Sender:=20; bh=8J6wAmSHQsQksyU97i/u154O/mDgig92QUJXPspWcu8=; b=tPi3T0JoF55Xi8d/xg901MysKy51zMsxFYpujOPXM+e0FO3RWxblKDF3ihTrZNmCU3vmVstO 0ZGl8UBnJYHTEhLlMOxerVDUjH/8ledz76bc2RTVAknpHFaJ9MmxDHe9; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Subject: [FECFRAME-PROTO] SDP params for FEC X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org 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 =20 > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com]=20 > Sent: Sunday, September 02, 2007 7:03 PM > To: Michael Bany > Cc: Ali Begen (abegen); Ulas Kozat; Marshall Eubanks; Mark=20 > Pullen; fecframe-proto@ietf.org; Shiloh Dorgan > Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax >=20 > Yes, a bit.. Sorry I haven't sent something out before but=20 > I've been on the road the past week and still have more road ahead. >=20 > What we need first is for someone to volunteer to outline the=20 > current relevant work from the other groups, ie RMT >=20 > Mark is the primary keeper of our requirements draft so we=20 > need confirmation that he will be able to make the interim meeting. >=20 > Then with the requirements and an understanding of the=20 > current relevant work we can begin to address what extensions=20 > are necessary to meet our goals of FECFrame. >=20 > So who is willing and able to provide the outline of current=20 > relevant work? >=20 > Thanks, > Greg >=20 > On 9/2/07, Michael Bany 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=20 > in Fairfax > > > > > > > > > > I will be driving from RTP on Saturday. So, I can join a dinner on=20 > > Sunday if anybody interested. I'll leave at 8pm on 18th out of DCA.=20 > > 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=20 > in Fairfax > > > > I will be arriving late night Sunday and depart out of=20 > Reagan National=20 > > 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=20 > in Fairfax > > > > > > > > > > Greetings-- > > > > I will be arriving late night Sunday and return back on 18th (my=20 > > reserved flight leaves at 4:45pm from Reagan National). > > > > Do we have a tentative schedule/agenda? If the meetings=20 > will continue=20 > > until late evening on 18th, I might change my schedule. > > > > Ulas > > > > > > On 8/30/07, Marshall Eubanks wrote: > > > > OK, having waited for the dust to settle, and having polled the =20 > > members who wanted the other dates, the Design team=20 > meeting will be=20 > > at George Mason University 17-18 September. Our thanks to GMU for=20 > > 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=20 > access to =20 > > 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=20 > short cab ride =20 > > 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=20 > National or =20 > > Dulles will cost order $ 30, maybe more from Dulles. > > > > If anyone does not plan to have a car, please let me know.=20 > I can pick =20 > > up a limited number or people on the way in each morning.=20 > Like many =20 > > American suburbs, you will feel limited if you do not have=20 > a car, but =20 > > 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=20 > 1 and 1/2 =20 > > hour drive away at best and you have to go through or around =20 > > Washington itself. I would not recommend it unless the flights are =20 > > really cheap. > > > > Be warned that DC has a very strong and typical rush=20 > "hour" (~6:30 =20 > > to 9:00 AM, ~4:00 to 7:00 PM). There will probably be=20 > little traffic =20 > > 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=20 > directions =20 > > > 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=20 > you should =20 > > >> know that while the room will be provided at no cost, the >>=20 > > participants will need to pay ($7/day if it has not gone=20 > up) >> for=20 > > parking. They should use the parking desk and pay there. > > >> The alternative is public transport- the Fairfax/GMU=20 > CUE bus >>=20 > > provides an inexpensive shuttle to Vienna Metro and area hotels >>=20 > > (see www.gmu.edu for info). > > >> > > >> Assuming the above is OK, I'm asking Shiloh to reserve=20 > a room >>=20 > > 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 =20 > > >>> Fecframe IETF working group. > > >>> > > >>> Fecframe is a new working group with a charter to >>> >>>=20 > > ...develop specifications for using >>> forward error correction=20 > > (FEC) codes with applications in the >>> Internet >>> to provide=20 > > protection against packet loss. The group will develop a =20 > >>> protocol=20 > > framework for application of FEC codes to arbitrary packet =20 > >>> flows=20 > > over unreliable transport protocols over both IP multicast and >>>=20 > > unicast. > > >>> > > >>> This has the potential to become an essential piece of=20 > technology =20 > > >>> underpinning IPTV. > > >>> > > >>> We need to have a meeting of the design team (6=20 > people), and have =20 > > >>> settled on the week of >>> September 17th. We estimate=20 > that this=20 > > will require the use of a >>> room for a day and a half,=20 > but I would =20 > > >>> like to secure a room for 2 days in total (9 to 5) in=20 > case we run =20 > > >>> long. > > >>> > > >>> At present, I think that everyone is available for the entire =20 > > >>> week, and so room availability could determine >>>=20 > which two days=20 > > 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=20 > 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 > > > > >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Mon Sep 10 19:05:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsKD-0001Mr-14; Mon, 10 Sep 2007 19:05:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsKC-0001Mm-M0 for fecframe-proto@ietf.org; Mon, 10 Sep 2007 19:05:48 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUsKB-00007j-HZ for fecframe-proto@ietf.org; Mon, 10 Sep 2007 19:05:48 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Sep 2007 23:06:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 10 Sep 2007 16:05:33 -0700 Subject: Re: [FECFRAME-PROTO] SDP params for FEC From: Mark Watson To: "Ali Begen (abegen)" , Message-ID: Thread-Topic: [FECFRAME-PROTO] SDP params for FEC Thread-Index: Acftzox5XqhdEoF6Sh2UTLCHdyT+PAGJ+5xwAAInACc= In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org 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)" 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 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 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 13:25:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsRO-0005KG-MB; Thu, 13 Sep 2007 13:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsRN-0005K9-CS for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:25:21 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVsRM-0002Ar-5U for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:25:21 -0400 Received: by nz-out-0506.google.com with SMTP id n1so423274nzf for ; Thu, 13 Sep 2007 10:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DH6mJqlpcA8k+PCPSdKLjzHMsIdDZlWtQ+u1VY88+Yw=; b=a24PfYl5Ep3yDfWhKnjqj1u+8S3TiOiBEDKLRGahIiMHspvLPLkHZ9sqlZvwXVGXyKyMIOYCE2ZQNjZ8YWXmCTjJGv4Sf7zae6eNnalMC+xIVm46Xhmt5XmF2u/gD9YtCwelaXNzzXfyj219/xyWPK5vBctQNFNZd/YKo42txgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=borYxTCVXECisPfzuoRV91LJ6LYFUXYooaZm5sKW5gw/5wLIBkQTzvf/gMREKTFkhCidCBtxZLBR0za/MTTwL6fpPJj+tPxTxf/tzM7Ggyn1E+aPxT6cTVPtfZ3PUwy0IBoxwHm6LvVvrMXClesDEAPscO0FkqQ7wqoNkByC1Jw= Received: by 10.114.146.1 with SMTP id t1mr722333wad.1189704319232; Thu, 13 Sep 2007 10:25:19 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Thu, 13 Sep 2007 10:25:19 -0700 (PDT) Message-ID: <38c19b540709131025x757133e2w723fc74fe9f76837@mail.gmail.com> Date: Thu, 13 Sep 2007 10:25:19 -0700 From: "Greg Shepherd" To: "Marshall Eubanks" Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax In-Reply-To: <9D139D6F-82C2-4CD3-9CD4-D4E7EAB2251B@multicasttech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5F47A4B4-9ED1-4CCD-9A3E-AAB145209977@multicasttech.com> <46CC1E5F.4090508@c4i.gmu.edu> <9D139D6F-82C2-4CD3-9CD4-D4E7EAB2251B@multicasttech.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Shiloh Dorgan , Mark Pullen , fecframe-proto@ietf.org X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Marshall, Were do we gather on the GME campus? Thanks, Greg On 8/30/07, Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 13:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsZg-00021e-18; Thu, 13 Sep 2007 13:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsZe-00020F-Pa for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:33:54 -0400 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVsZd-0002Me-0W for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:33:54 -0400 Received: by wa-out-1112.google.com with SMTP id k40so917219wah for ; Thu, 13 Sep 2007 10:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=14rsPC8IpKz+Sq0hrOWVPSW3WOALvbWJW3+olqVrO1s=; b=agOcFpqDVQucXAbt1MAqfee9fqXJ8mum9IWT148/tEU9/kDYuDPNSm6xxV2rO3uKEAbcs91NfuYT/JQa56Zt6zw44zgfM1eq4Xx2IeQaiJDb+EPeIeWM+uGytQJ6kxAGzhruKo3O/uZvNFFFe9YQSMZKY3BusRgE1sJTtvIGq+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hE8zd1uTR7HSeL0/0LhfENryNjbX5OXSzfch3QFP8eIhuaZpKrsyitl6B52wE//to8xGmv0W9O3w3IhJJDDdfhm9jlz59H9ymtu3X+4ejmshOUm+40DvZeyHN7RGnb7dQfUn8h/UPCz4gHoSH/2n8Pg9SN2RgbeipZ+BMTJd+cE= Received: by 10.115.106.7 with SMTP id i7mr729510wam.1189704830882; Thu, 13 Sep 2007 10:33:50 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Thu, 13 Sep 2007 10:33:50 -0700 (PDT) Message-ID: <38c19b540709131033h4092d9a9tfb72a4edeb3492c8@mail.gmail.com> Date: Thu, 13 Sep 2007 10:33:50 -0700 From: "Greg Shepherd" To: "Mark Watson" Subject: Re: [FECFRAME-PROTO] SDP params for FEC In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On 9/10/07, Mark Watson wrote: > 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. 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 > ...Mark > > > On 9/10/07 3:18 PM, "Ali Begen (abegen)" 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 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 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 13:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVscs-0006WH-9g; Thu, 13 Sep 2007 13:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVscr-0006VM-DO for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:37:13 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVscp-0002QT-TX for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:37:13 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Sep 2007 17:38:19 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 13 Sep 2007 10:37:04 -0700 Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax From: Mark Watson To: Marshall Eubanks Message-ID: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Thread-Index: Acf2LLKs8YaNP2IfEdyMlQAX8sJN9g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org All, I am staying at the Marriott - is anyone else staying there and planning to get a car ? If so then I'll just get taxis to/from the airport. Anyone want to meet for a later dinner on Sunday ? I guess I'll get to the hotel around 8-8.30. ...Mark On 9/10/07 12:52 PM, "Marshall Eubanks" wrote: > > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > >> OK, I have called the >> >> Stafford House Bed & Breakfast >> 3746 Chain Bridge Road >> Fairfax, VA 22030 > > They have only 1 room available - a Suite with a King size bed. > > $ 159 for 1 person > $ 179 for 2 (but you have to share the bed) > > Regards > Marshall > >> >> to see if they have any room - they are the only one close enough >> to comfortably walk to GMU. I don't know if they are affordable, >> though. >> >> None of the others have the slightest bit of charm - I would >> recommend the >> >> Courtyard by Marriott - Fair Oaks >> 11220 Lee Jackson Hwy. >> Fairfax, VA 22030 >> >> It is easy to get to by car (just off I-66), and has bus ability too. >> >> Regards >> Marshall >> >> P.S. If any one wants to stay at >> Canary Cottage Bed & Breakfast >> >> ph: (703) 322-1811 >> >> 8.0 miles from Fairfax Campus >> 7153 Main Street >> Clifton, VA 20124 >> >> let me know - I live in Clifton and can give you a ride. >> >> >> Begin forwarded message: >> >>> From: Shiloh Dorgan >>> Date: August 30, 2007 9:51:31 AM EDT >>> To: Marshall Eubanks >>> Cc: fecframe-proto@ietf.org, Mark Pullen >>> Subject: Re: FECFRAME Design Meeting in Fairfax >>> >>> Here are the details:: >>> >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >>> >>> 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. >>> >>> Shiloh >>> >>> Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 13:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsqy-0005FO-Pf; Thu, 13 Sep 2007 13:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsqx-0005FJ-Cc for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:51:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVsqw-0002ht-8t for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:51:47 -0400 X-IronPort-AV: E=Sophos;i="4.20,250,1186383600"; d="scan'208";a="217602895" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Sep 2007 10:51:45 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8DHpjQF004037; Thu, 13 Sep 2007 10:51:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DHpgFA008695; Thu, 13 Sep 2007 17:51:44 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 10:51:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Thu, 13 Sep 2007 10:51:35 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405263D40@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax thread-index: Acf2LLKs8YaNP2IfEdyMlQAX8sJN9gAAYBig References: From: "Ali Begen \(abegen\)" To: "Mark Watson" , "Marshall Eubanks" X-OriginalArrivalTime: 13 Sep 2007 17:51:38.0056 (UTC) FILETIME=[BBA6FC80:01C7F62E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8670; t=1189705905; x=1190569905; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Fwd=3A=20FECFRAME=20Design=20Meeti ng=20in=20Fairfax |Sender:=20; bh=Lra8w/7vczaJfr3g54UB1ce1iiqnb/8t1UWTeHR3oGE=; b=eLZLLZIHwrV7WwDwP+wVsxwOa2mFUhJjc65dgze86P43nEgUzsYxxGWzb9TzSIUR3Bafv8Bh gIaU4QACfzu8pbAean9bC5xB5hQ8eJJfjqgjtFgPiwWH7y4L7q9NpfyC; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I am in for the dinner. I have a car but I am staying at=20 HAMPTON INN FAIRFAX CITY 10860 LEE HIGHWAY Fairfax, VA 22030 I can pick you up, if you want. Let me know the address.=20 Anybody else? (Sorry, I got a two-door mustang this time :), so we can at most fit 4 people at the same time) -acbegen=20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Thursday, September 13, 2007 10:37 AM > To: Marshall Eubanks > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > All, >=20 > I am staying at the Marriott - is anyone else staying there=20 > and planning to get a car ? If so then I'll just get taxis=20 > to/from the airport. >=20 > Anyone want to meet for a later dinner on Sunday ? I guess=20 > I'll get to the hotel around 8-8.30. >=20 > ...Mark >=20 >=20 > On 9/10/07 12:52 PM, "Marshall Eubanks" wrote: >=20 > >=20 > > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > >=20 > >> OK, I have called the > >>=20 > >> Stafford House Bed & Breakfast > >> 3746 Chain Bridge Road > >> Fairfax, VA 22030 > >=20 > > They have only 1 room available - a Suite with a King size bed. > >=20 > > $ 159 for 1 person > > $ 179 for 2 (but you have to share the bed) > >=20 > > Regards > > Marshall > >=20 > >>=20 > >> to see if they have any room - they are the only one close=20 > enough to=20 > >> comfortably walk to GMU. I don't know if they are=20 > affordable, though. > >>=20 > >> None of the others have the slightest bit of charm - I would=20 > >> recommend the > >>=20 > >> Courtyard by Marriott - Fair Oaks > >> 11220 Lee Jackson Hwy. > >> Fairfax, VA 22030 > >>=20 > >> It is easy to get to by car (just off I-66), and has bus=20 > ability too. > >>=20 > >> Regards > >> Marshall > >>=20 > >> P.S. If any one wants to stay at > >> Canary Cottage Bed & Breakfast > >>=20 > >> ph: (703) 322-1811 > >>=20 > >> 8.0 miles from Fairfax Campus > >> 7153 Main Street > >> Clifton, VA 20124 > >>=20 > >> let me know - I live in Clifton and can give you a ride. > >>=20 > >>=20 > >> Begin forwarded message: > >>=20 > >>> From: Shiloh Dorgan > >>> Date: August 30, 2007 9:51:31 AM EDT > >>> To: Marshall Eubanks > >>> Cc: fecframe-proto@ietf.org, Mark Pullen > >>> Subject: Re: FECFRAME Design Meeting in Fairfax > >>>=20 > >>> Here are the details:: > >>>=20 > >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > >>>=20 > >>> Directions to meeting location (Science & Technology II bldg, room > >>> 320): > >>> Park in the Sandy Creek parking deck: http://coyote.gmu.edu/map/=20 > >>> maphtml/parkingdeck2.html Walk across the road to the Science &=20 > >>> Technology II bldg, it is within view from the parking deck:=20 > >>> http://coyote.gmu.edu/map/ maphtml/st21.html Elevator to=20 > the third=20 > >>> floor, turn left, go to the end of the hall, turn right=20 > and on your=20 > >>> right will be the conference room, room 320. > >>>=20 > >>> Shiloh > >>>=20 > >>> Marshall Eubanks wrote: > >>>> OK, having waited for the dust to settle, and having polled the=20 > >>>> members who wanted the other dates, the Design team=20 > meeting will be=20 > >>>> at George Mason University 17-18 September. Our thanks=20 > to GMU for=20 > >>>> offering the space. > >>>>=20 > >>>> Mark, Shiloh, can you recommend a nearby hotel ? > >>>>=20 > >>>> Also, we will need directions to the exact site of the meeting. > >>>>=20 > >>>> Travel arrangements : > >>>>=20 > >>>> Either Dulles (IAD) or National (DCA) airports have easy=20 > access to=20 > >>>> GMU in Fairfax, Virginia. > >>>>=20 > >>>> National even has subway (Metro) access - > >>>>=20 > >>>> http://www.wmata.com/metrorail/systemmap.cfm > >>>>=20 > >>>> Blue line to the Orange line, Orange line to Vienna, a short cab=20 > >>>> ride or CUE bus ride to GMU. > >>>>=20 > >>>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp > >>>>=20 > >>>> I would allow at least an hour for this. A cab ride from=20 > National=20 > >>>> or Dulles will cost order $ 30, maybe more from Dulles. > >>>>=20 > >>>> If anyone does not plan to have a car, please let me know. I can=20 > >>>> 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=20 > >>>> have a car, but it is possible. The GMU campus itself is pretty=20 > >>>> spread out. > >>>>=20 > >>>> http://coyote.gmu.edu/map/fairfax.html > >>>>=20 > >>>> 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=20 > >>>> Washington itself. I would not recommend it unless the=20 > flights are=20 > >>>> really cheap. > >>>>=20 > >>>> Be warned that DC has a very strong and typical rush=20 > "hour" (~6:30=20 > >>>> to 9:00 AM, ~4:00 to 7:00 PM). There will probably be little=20 > >>>> traffic on Sunday. > >>>>=20 > >>>> If people come in early enough Sunday night we should=20 > have dinner. > >>>>=20 > >>>> Regards > >>>> Marshall > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: > >>>>=20 > >>>>> Room 320 is reserved for the FECFRAME meeting 17-18 September. > >>>>> Parking is $8/day. Let me know if anyone needs links for=20 > >>>>> directions or has any questions. > >>>>>=20 > >>>>> Shiloh > >>>>>=20 > >>>>> Mark Pullen wrote: > >>>>>> Marshall, > >>>>>>=20 > >>>>>> 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=20 > >>>>>> should know that while the room will be provided at no=20 > cost, the=20 > >>>>>> participants will need to pay ($7/day if it has not=20 > gone up) for=20 > >>>>>> parking. They should use the parking desk and pay there. > >>>>>> The alternative is public transport- the Fairfax/GMU CUE bus=20 > >>>>>> provides an inexpensive shuttle to Vienna Metro and=20 > area hotels=20 > >>>>>> (see www.gmu.edu for info). > >>>>>>=20 > >>>>>> Assuming the above is OK, I'm asking Shiloh to reserve=20 > a room for=20 > >>>>>> you (Shiloh, start with 320 ST2 if available). > >>>>>>=20 > >>>>>> Mark > >>>>>>=20 > >>>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: > >>>>>>=20 > >>>>>>> Dear Mark; > >>>>>>>=20 > >>>>>>> I am trying to find a place for a design team meeting for the=20 > >>>>>>> Fecframe IETF working group. > >>>>>>>=20 > >>>>>>> Fecframe is a new working group with a charter to > >>>>>>>=20 > >>>>>>> ...develop specifications for using forward error correction=20 > >>>>>>> (FEC) codes with applications in the Internet to provide=20 > >>>>>>> protection against packet loss. The group will develop a=20 > >>>>>>> protocol framework for application of FEC codes to arbitrary=20 > >>>>>>> packet flows over unreliable transport protocols over both IP=20 > >>>>>>> multicast and unicast. > >>>>>>>=20 > >>>>>>> This has the potential to become an essential piece of=20 > >>>>>>> technology underpinning IPTV. > >>>>>>>=20 > >>>>>>> We need to have a meeting of the design team (6 people), and=20 > >>>>>>> have settled on the week of September 17th. We estimate that=20 > >>>>>>> this will require the use of a room for a day and a=20 > half, but I=20 > >>>>>>> would like to secure a room for 2 days in total (9 to=20 > 5) in case=20 > >>>>>>> we run long. > >>>>>>>=20 > >>>>>>> At present, I think that everyone is available for the entire=20 > >>>>>>> week, and so room availability could determine which=20 > two days we=20 > >>>>>>> meet. > >>>>>>>=20 > >>>>>>> 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=20 > >>>>>>> think. > >>>>>>>=20 > >>>>>>> Regards > >>>>>>> Marshall > >>>>>>>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> FECFRAME-PROTO mailing list > >> FECFRAME-PROTO@ietf.org > >> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 >=20 > _______________________________________________ > FECFRAME-PROTO mailing list > FECFRAME-PROTO@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Thu Sep 13 13:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVstB-0007M5-3v; Thu, 13 Sep 2007 13:54:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVst9-0007Fo-II for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:54:03 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVst8-0004Bb-QZ for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:54:03 -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 8432872; Thu, 13 Sep 2007 13:54:00 -0400 In-Reply-To: <38c19b540709131025x757133e2w723fc74fe9f76837@mail.gmail.com> References: <5F47A4B4-9ED1-4CCD-9A3E-AAB145209977@multicasttech.com> <46CC1E5F.4090508@c4i.gmu.edu> <9D139D6F-82C2-4CD3-9CD4-D4E7EAB2251B@multicasttech.com> <38c19b540709131025x757133e2w723fc74fe9f76837@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7C399DCB-B147-42F0-B51E-DA8C38E221E5@multicasttech.com> Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting in Fairfax Date: Thu, 13 Sep 2007 13:53:55 -0400 To: "Greg Shepherd" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: Shiloh Dorgan , Mark Pullen , fecframe-proto@ietf.org X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On Sep 13, 2007, at 1:25 PM, Greg Shepherd wrote: > Marshall, > > 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/=20 maphtml/parkingdeck2.html Walk across the road to the Science & Technology II bldg, it is =20 within view from the parking deck: http://coyote.gmu.edu/map/maphtml/=20 st21.html Elevator to the third floor, turn left, go to the end of the hall, =20 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) =20 at, say, 8:30 http://coyote.gmu.edu/map/maphtml/gwjc1.html Johnson Center: Ground Floor: Mason's own Jazzman's Caf=E9 and the Bistro are popular =20= partners on the ground floor of the Johnson Center. Jazzman's =20 features live music and cool jazz, signature pastries, salads, =20 sandwiches, and the full range of coffee drinks and teas a la =20 Seattle's Best, while the Bistro offers a wide variety of carefully =20 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=EBns Caf=E9 with great coffees, local baked goods, and a New York-style deli =20= counter at La Patisserie All the best of Starbuck's, and the convenience of grab and go can be =20= found at the Express Third Floor: George's Restaurant features well-rounded hot and cold =20 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 =20 AFAIK no great breakfast places in Fairfax City, so we might as well meet at the Marriot. Regards Marshall > > Thanks, > Greg > > On 8/30/07, Marshall Eubanks 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 =20 >>>>> develop a >>>>> protocol framework for application of FEC codes to arbitrary =20 >>>>> packet >>>>> flows over unreliable transport protocols over both IP =20 >>>>> 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 =20 >>>>> 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 14:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt0l-0001v1-J3; Thu, 13 Sep 2007 14:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt0j-0001rl-LX for fecframe-proto@ietf.org; Thu, 13 Sep 2007 14:01:53 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVt0i-0002up-Ci for fecframe-proto@ietf.org; Thu, 13 Sep 2007 14:01:53 -0400 Received: by an-out-0708.google.com with SMTP id c17so93829anc for ; Thu, 13 Sep 2007 11:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=WOA7kFyCEFVtwMrJvw2+K/lRWfBkPnTt7WcdJuhT+50=; b=VRg6QYdZQ/uRrJ3spMZ8/ZqywMuxz1Fv/8PcHAjYOKAqs40ADNEhVXNWa/YwZ1wa0/OuPx+0nm3igHPL7Ig3HNlJ5luTzOKqzAkdPSsH5jlTD3udew93EGr5nraIjv2y1bHhWgrj0IhATp4Qn4JvFtsTqxTOmgpywmpHbi8/jsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AbArfMdIi+WM0H1Eu2GS/N34tXdgeLf31lneW2YEOd2EPdW2yunMAwzLsiPU2c3p+xIezr2vupPRAhayWw37Lx3E3mI0uCi3CmjgERb3/enbI5dl1Dw1BM7b10SxR44eZKhfIhIhn1dOXTMgWecHGz9QsKyoHE5tGaoIgPWrOe8= Received: by 10.143.42.3 with SMTP id u3mr167635wfj.1189706511093; Thu, 13 Sep 2007 11:01:51 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Thu, 13 Sep 2007 11:01:51 -0700 (PDT) Message-ID: <38c19b540709131101r34ae448ax913c3a867f729f7@mail.gmail.com> Date: Thu, 13 Sep 2007 11:01:51 -0700 From: "Greg Shepherd" To: "Ali Begen (abegen)" Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405263D40@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5405263D40@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I'm staying at: Hilton Garden Inn Fairfax 3950 Fair Ridge Drive Fairfax, VA 22030 Looks like we're scattered.. I'll try to switch to the Marriott, and I will have a car. Plus, I think Mark and I are on the same plane out of Dulles on Tuesday evening. Greg On 9/13/07, Ali Begen (abegen) wrote: > I am in for the dinner. I have a car but I am staying at > > HAMPTON INN FAIRFAX CITY > 10860 LEE HIGHWAY > Fairfax, VA 22030 > > I can pick you up, if you want. Let me know the address. > > Anybody else? (Sorry, I got a two-door mustang this time :), so we can > at most fit 4 people at the same time) > > -acbegen > > > -----Original Message----- > > From: Mark Watson [mailto:mark@digitalfountain.com] > > Sent: Thursday, September 13, 2007 10:37 AM > > To: Marshall Eubanks > > Cc: fecframe-proto@ietf.org > > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > > > All, > > > > I am staying at the Marriott - is anyone else staying there > > and planning to get a car ? If so then I'll just get taxis > > to/from the airport. > > > > Anyone want to meet for a later dinner on Sunday ? I guess > > I'll get to the hotel around 8-8.30. > > > > ...Mark > > > > > > On 9/10/07 12:52 PM, "Marshall Eubanks" wrote: > > > > > > > > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > > > > > >> OK, I have called the > > >> > > >> Stafford House Bed & Breakfast > > >> 3746 Chain Bridge Road > > >> Fairfax, VA 22030 > > > > > > They have only 1 room available - a Suite with a King size bed. > > > > > > $ 159 for 1 person > > > $ 179 for 2 (but you have to share the bed) > > > > > > Regards > > > Marshall > > > > > >> > > >> to see if they have any room - they are the only one close > > enough to > > >> comfortably walk to GMU. I don't know if they are > > affordable, though. > > >> > > >> None of the others have the slightest bit of charm - I would > > >> recommend the > > >> > > >> Courtyard by Marriott - Fair Oaks > > >> 11220 Lee Jackson Hwy. > > >> Fairfax, VA 22030 > > >> > > >> It is easy to get to by car (just off I-66), and has bus > > ability too. > > >> > > >> Regards > > >> Marshall > > >> > > >> P.S. If any one wants to stay at > > >> Canary Cottage Bed & Breakfast > > >> > > >> ph: (703) 322-1811 > > >> > > >> 8.0 miles from Fairfax Campus > > >> 7153 Main Street > > >> Clifton, VA 20124 > > >> > > >> let me know - I live in Clifton and can give you a ride. > > >> > > >> > > >> Begin forwarded message: > > >> > > >>> From: Shiloh Dorgan > > >>> Date: August 30, 2007 9:51:31 AM EDT > > >>> To: Marshall Eubanks > > >>> Cc: fecframe-proto@ietf.org, Mark Pullen > > >>> Subject: Re: FECFRAME Design Meeting in Fairfax > > >>> > > >>> Here are the details:: > > >>> > > >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > > >>> > > >>> 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. > > >>> > > >>> Shiloh > > >>> > > >>> Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Thu Sep 13 14:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt4r-0001YO-DF; Thu, 13 Sep 2007 14:06:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt4q-0001Pi-7j for fecframe-proto@ietf.org; Thu, 13 Sep 2007 14:06:08 -0400 Received: from www.amesweb.com ([216.218.233.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVt4p-0004SJ-8J for fecframe-proto@ietf.org; Thu, 13 Sep 2007 14:06:08 -0400 Received: from mega-shasta-1-149-ip.dsl.netins.net ([199.120.78.149] helo=exchange.amesweb.com) by www.amesweb.com with esmtp (Exim 4.10) id 1IVt4o-0001NW-00 for fecframe-proto@ietf.org; Thu, 13 Sep 2007 13:06:06 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 13 Sep 2007 13:05:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Thread-Index: Acf2LLKs8YaNP2IfEdyMlQAX8sJN9gAAxqKQ References: From: "Michael Bany" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I am staying at the Marriot and I have a car. I won't arrive until 11:30 pm though. I am going in and out of National. -----Original Message----- From: Mark Watson [mailto:mark@digitalfountain.com]=20 Sent: Thursday, September 13, 2007 12:37 PM To: Marshall Eubanks Cc: fecframe-proto@ietf.org Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax All, I am staying at the Marriott - is anyone else staying there and planning to get a car ? If so then I'll just get taxis to/from the airport. Anyone want to meet for a later dinner on Sunday ? I guess I'll get to the hotel around 8-8.30. ...Mark On 9/10/07 12:52 PM, "Marshall Eubanks" wrote: >=20 > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: >=20 >> OK, I have called the >>=20 >> Stafford House Bed & Breakfast >> 3746 Chain Bridge Road >> Fairfax, VA 22030 >=20 > They have only 1 room available - a Suite with a King size bed. >=20 > $ 159 for 1 person > $ 179 for 2 (but you have to share the bed) >=20 > Regards > Marshall >=20 >>=20 >> to see if they have any room - they are the only one close enough >> to comfortably walk to GMU. I don't know if they are affordable, >> though. >>=20 >> None of the others have the slightest bit of charm - I would >> recommend the >>=20 >> Courtyard by Marriott - Fair Oaks >> 11220 Lee Jackson Hwy. >> Fairfax, VA 22030 >>=20 >> It is easy to get to by car (just off I-66), and has bus ability too. >>=20 >> Regards >> Marshall >>=20 >> P.S. If any one wants to stay at >> Canary Cottage Bed & Breakfast >>=20 >> ph: (703) 322-1811 >>=20 >> 8.0 miles from Fairfax Campus >> 7153 Main Street >> Clifton, VA 20124 >>=20 >> let me know - I live in Clifton and can give you a ride. >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Shiloh Dorgan >>> Date: August 30, 2007 9:51:31 AM EDT >>> To: Marshall Eubanks >>> Cc: fecframe-proto@ietf.org, Mark Pullen >>> Subject: Re: FECFRAME Design Meeting in Fairfax >>>=20 >>> Here are the details:: >>>=20 >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >>>=20 >>> 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. >>>=20 >>> Shiloh >>>=20 >>> Marshall Eubanks 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. >>>>=20 >>>> Mark, Shiloh, can you recommend a nearby hotel ? >>>>=20 >>>> Also, we will need directions to the exact site of the meeting. >>>>=20 >>>> Travel arrangements : >>>>=20 >>>> Either Dulles (IAD) or National (DCA) airports have easy access >>>> to GMU in Fairfax, Virginia. >>>>=20 >>>> National even has subway (Metro) access - >>>>=20 >>>> http://www.wmata.com/metrorail/systemmap.cfm >>>>=20 >>>> Blue line to the Orange line, Orange line to Vienna, a short cab >>>> ride or CUE bus ride to GMU. >>>>=20 >>>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp >>>>=20 >>>> I would allow at least an hour for this. A cab ride from National >>>> or Dulles will cost order $ 30, maybe more from Dulles. >>>>=20 >>>> 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. >>>>=20 >>>> http://coyote.gmu.edu/map/fairfax.html >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> If people come in early enough Sunday night we should have dinner. >>>>=20 >>>> Regards >>>> Marshall >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> Shiloh >>>>>=20 >>>>> Mark Pullen wrote: >>>>>> Marshall, >>>>>>=20 >>>>>> 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). >>>>>>=20 >>>>>> Assuming the above is OK, I'm asking Shiloh to reserve a room >>>>>> for you (Shiloh, start with 320 ST2 if available). >>>>>>=20 >>>>>> Mark >>>>>>=20 >>>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: >>>>>>=20 >>>>>>> Dear Mark; >>>>>>>=20 >>>>>>> I am trying to find a place for a design team meeting for the >>>>>>> Fecframe IETF working group. >>>>>>>=20 >>>>>>> Fecframe is a new working group with a charter to >>>>>>>=20 >>>>>>> ...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. >>>>>>>=20 >>>>>>> This has the potential to become an essential piece of >>>>>>> technology underpinning IPTV. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> At present, I think that everyone is available for the entire >>>>>>> week, and so room availability could determine >>>>>>> which two days we meet. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Regards >>>>>>> Marshall >>>>>>>=20 >>=20 >>=20 >> _______________________________________________ >> FECFRAME-PROTO mailing list >> FECFRAME-PROTO@ietf.org >> https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 >=20 > _______________________________________________ > 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 From fecframe-proto-bounces@ietf.org Sun Sep 16 01:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmIH-0004de-Ry; Sun, 16 Sep 2007 01:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmIH-0004dZ-7C for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:03:41 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWmIF-0002Hh-Pz for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:03:41 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2062450wah for ; Sat, 15 Sep 2007 22:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Xp3hfbsrG1vRpY1dTiHrxIgCYnpuLKTLZu36tT1SC2I=; b=s6smfG3FPR0rGSjVAB6IymVyuRaKfgXrIEB4HN7XvTvMIp9sJP59qgz4Oakd0L+zJK3F9r9PPe8MVJO5EJ4CMsK7foFTznQsfOp5W6H5jFmuYVWIgGuQGXnlKQKOsEXnSQj6Ol1hsCdNWbfQ/tolSS3xUiQy0X4FKc9mvBU76NQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hR/7JQEuE08efVe2dPzDq4m9qfkXwTSOCO7gAJDMmDuSlZr2upUvAZb7K72/mpY+VOaSQOqJfMVWu2z69vF16+wzqSPY1ATWzYHB4+q0+snpQSkPg0CutvIlWf8qJj/Zfkq/1GZnCbuZqpedEbUKlMHbNf6m0l3zG1zyC7045cM= Received: by 10.115.32.1 with SMTP id k1mr2623108waj.1189919018209; Sat, 15 Sep 2007 22:03:38 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Sat, 15 Sep 2007 22:03:38 -0700 (PDT) Message-ID: <38c19b540709152203j164ca8dcq4d789219389528be@mail.gmail.com> Date: Sat, 15 Sep 2007 22:03:38 -0700 From: "Greg Shepherd" To: "Michael Bany" Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I arrive late afternoon on Sunday. For those coming in Sunday who would like to get together for dinner, let's connect on the phone. My cell is: 541-915-4989 Greg On 9/13/07, Michael Bany wrote: > I am staying at the Marriot and I have a car. I won't arrive until > 11:30 pm though. > > I am going in and out of National. > > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com] > Sent: Thursday, September 13, 2007 12:37 PM > To: Marshall Eubanks > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > All, > > I am staying at the Marriott - is anyone else staying there and planning > to > get a car ? If so then I'll just get taxis to/from the airport. > > Anyone want to meet for a later dinner on Sunday ? I guess I'll get to > the > hotel around 8-8.30. > > ...Mark > > > On 9/10/07 12:52 PM, "Marshall Eubanks" wrote: > > > > > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > > > >> OK, I have called the > >> > >> Stafford House Bed & Breakfast > >> 3746 Chain Bridge Road > >> Fairfax, VA 22030 > > > > They have only 1 room available - a Suite with a King size bed. > > > > $ 159 for 1 person > > $ 179 for 2 (but you have to share the bed) > > > > Regards > > Marshall > > > >> > >> to see if they have any room - they are the only one close enough > >> to comfortably walk to GMU. I don't know if they are affordable, > >> though. > >> > >> None of the others have the slightest bit of charm - I would > >> recommend the > >> > >> Courtyard by Marriott - Fair Oaks > >> 11220 Lee Jackson Hwy. > >> Fairfax, VA 22030 > >> > >> It is easy to get to by car (just off I-66), and has bus ability too. > >> > >> Regards > >> Marshall > >> > >> P.S. If any one wants to stay at > >> Canary Cottage Bed & Breakfast > >> > >> ph: (703) 322-1811 > >> > >> 8.0 miles from Fairfax Campus > >> 7153 Main Street > >> Clifton, VA 20124 > >> > >> let me know - I live in Clifton and can give you a ride. > >> > >> > >> Begin forwarded message: > >> > >>> From: Shiloh Dorgan > >>> Date: August 30, 2007 9:51:31 AM EDT > >>> To: Marshall Eubanks > >>> Cc: fecframe-proto@ietf.org, Mark Pullen > >>> Subject: Re: FECFRAME Design Meeting in Fairfax > >>> > >>> Here are the details:: > >>> > >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > >>> > >>> 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. > >>> > >>> Shiloh > >>> > >>> Marshall Eubanks 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 From fecframe-proto-bounces@ietf.org Sun Sep 16 01:08:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmMh-0000DI-2O; Sun, 16 Sep 2007 01:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmMg-0000DD-E1 for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:08:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWmMe-0002LH-TU for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:08:14 -0400 X-IronPort-AV: E=Sophos;i="4.20,259,1186383600"; d="scan'208";a="10155389" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 15 Sep 2007 22:08:08 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8G588NL024874; Sat, 15 Sep 2007 22:08:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8G583dr019255; Sun, 16 Sep 2007 05:08:03 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 22:08:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Sat, 15 Sep 2007 22:07:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540709152203j164ca8dcq4d789219389528be@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax thread-index: Acf4Hvsw1iXgof2RRx2mxnv87/OLQAAADPxA References: <38c19b540709152203j164ca8dcq4d789219389528be@mail.gmail.com> From: "Ali Begen \(abegen\)" To: "Greg Shepherd" , "Michael Bany" X-OriginalArrivalTime: 16 Sep 2007 05:08:03.0513 (UTC) FILETIME=[8F4BC290:01C7F81F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9790; t=1189919288; x=1190783288; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Fwd=3A=20FECFRAME=20Design=20Meeti ng=20in=20Fairfax |Sender:=20; bh=AG3JXwPyGBpEu5eAtd2Dg2c2la9HbjnC5kmvozgFrjg=; b=1qK2jAvjIOmkzTYoIuLfFBx+2c4AA5H2sY7wBWdDN5EtJbb8vPpNRa3a6VSYEPbXhnzcMUer lWB/ESMMNMJe8xNZuK6nuu434pI6gdUewlMVYW1p2FkiaP4Rkihg82tC; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org My cell is 404-513-3694. I can join the dinner if it is going to be after 7:30pm. -acbegen > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com]=20 > Sent: Saturday, September 15, 2007 10:04 PM > To: Michael Bany > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > I arrive late afternoon on Sunday. For those coming in Sunday=20 > who would like to get together for dinner, let's connect on=20 > the phone. My cell is: >=20 > 541-915-4989 >=20 > Greg >=20 > On 9/13/07, Michael Bany wrote: > > I am staying at the Marriot and I have a car. I won't arrive until=20 > > 11:30 pm though. > > > > I am going in and out of National. > > > > -----Original Message----- > > From: Mark Watson [mailto:mark@digitalfountain.com] > > Sent: Thursday, September 13, 2007 12:37 PM > > To: Marshall Eubanks > > Cc: fecframe-proto@ietf.org > > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting=20 > in Fairfax > > > > All, > > > > I am staying at the Marriott - is anyone else staying there and=20 > > planning to get a car ? If so then I'll just get taxis to/from the=20 > > airport. > > > > Anyone want to meet for a later dinner on Sunday ? I guess=20 > I'll get to=20 > > the hotel around 8-8.30. > > > > ...Mark > > > > > > On 9/10/07 12:52 PM, "Marshall Eubanks"=20 > wrote: > > > > > > > > On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > > > > > >> OK, I have called the > > >> > > >> Stafford House Bed & Breakfast > > >> 3746 Chain Bridge Road > > >> Fairfax, VA 22030 > > > > > > They have only 1 room available - a Suite with a King size bed. > > > > > > $ 159 for 1 person > > > $ 179 for 2 (but you have to share the bed) > > > > > > Regards > > > Marshall > > > > > >> > > >> to see if they have any room - they are the only one=20 > close enough=20 > > >> to comfortably walk to GMU. I don't know if they are affordable,=20 > > >> though. > > >> > > >> None of the others have the slightest bit of charm - I would=20 > > >> recommend the > > >> > > >> Courtyard by Marriott - Fair Oaks > > >> 11220 Lee Jackson Hwy. > > >> Fairfax, VA 22030 > > >> > > >> It is easy to get to by car (just off I-66), and has bus=20 > ability too. > > >> > > >> Regards > > >> Marshall > > >> > > >> P.S. If any one wants to stay at > > >> Canary Cottage Bed & Breakfast > > >> > > >> ph: (703) 322-1811 > > >> > > >> 8.0 miles from Fairfax Campus > > >> 7153 Main Street > > >> Clifton, VA 20124 > > >> > > >> let me know - I live in Clifton and can give you a ride. > > >> > > >> > > >> Begin forwarded message: > > >> > > >>> From: Shiloh Dorgan > > >>> Date: August 30, 2007 9:51:31 AM EDT > > >>> To: Marshall Eubanks > > >>> Cc: fecframe-proto@ietf.org, Mark Pullen=20 > > > >>> Subject: Re: FECFRAME Design Meeting in Fairfax > > >>> > > >>> Here are the details:: > > >>> > > >>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > > >>> > > >>> Directions to meeting location (Science & Technology II=20 > bldg, room > > >>> 320): > > >>> Park in the Sandy Creek parking deck:=20 > http://coyote.gmu.edu/map/=20 > > >>> maphtml/parkingdeck2.html Walk across the road to the Science &=20 > > >>> Technology II bldg, it is within view from the parking deck:=20 > > >>> http://coyote.gmu.edu/map/ maphtml/st21.html Elevator=20 > to the third=20 > > >>> floor, turn left, go to the end of the hall, turn right and on=20 > > >>> your right will be the conference room, room 320. > > >>> > > >>> Shiloh > > >>> > > >>> Marshall Eubanks wrote: > > >>>> OK, having waited for the dust to settle, and having=20 > polled the=20 > > >>>> members who wanted the other dates, the Design team=20 > meeting will=20 > > >>>> be at George Mason University 17-18 September. Our=20 > thanks to GMU=20 > > >>>> 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=20 > easy access=20 > > >>>> 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=20 > short cab=20 > > >>>> 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=20 > from National=20 > > >>>> or Dulles will cost order $ 30, maybe more from Dulles. > > >>>> > > >>>> If anyone does not plan to have a car, please let me=20 > know. I can=20 > > >>>> pick up a limited number or people on the way in each morning. > > >>>> Like many American suburbs, you will feel limited if=20 > you do not=20 > > >>>> have a car, but it is possible. The GMU campus itself=20 > is pretty=20 > > >>>> 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=20 > or around=20 > > >>>> Washington itself. I would not recommend it unless the flights=20 > > >>>> are really cheap. > > >>>> > > >>>> Be warned that DC has a very strong and typical rush "hour"=20 > > >>>> (~6:30 to 9:00 AM, ~4:00 to 7:00 PM). There will probably be=20 > > >>>> little traffic on Sunday. > > >>>> > > >>>> If people come in early enough Sunday night we should=20 > 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=20 > > >>>>> 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=20 > > >>>>>> participants will need to pay ($7/day if it has not gone up)=20 > > >>>>>> for parking. They should use the parking desk and pay there. > > >>>>>> The alternative is public transport- the Fairfax/GMU CUE bus=20 > > >>>>>> provides an inexpensive shuttle to Vienna Metro and=20 > area hotels=20 > > >>>>>> (see www.gmu.edu for info). > > >>>>>> > > >>>>>> Assuming the above is OK, I'm asking Shiloh to=20 > reserve a room=20 > > >>>>>> 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=20 > meeting for the=20 > > >>>>>>> Fecframe IETF working group. > > >>>>>>> > > >>>>>>> Fecframe is a new working group with a charter to > > >>>>>>> > > >>>>>>> ...develop specifications for using forward error=20 > correction=20 > > >>>>>>> (FEC) codes with applications in the Internet to provide=20 > > >>>>>>> protection against packet loss. The group will develop a=20 > > >>>>>>> protocol framework for application of FEC codes to=20 > arbitrary=20 > > >>>>>>> packet flows over unreliable transport protocols=20 > over both IP=20 > > >>>>>>> multicast and unicast. > > >>>>>>> > > >>>>>>> This has the potential to become an essential piece of=20 > > >>>>>>> technology underpinning IPTV. > > >>>>>>> > > >>>>>>> We need to have a meeting of the design team (6=20 > people), and=20 > > >>>>>>> have settled on the week of September 17th. We=20 > estimate that=20 > > >>>>>>> this will require the use of a room for a day and a=20 > half, but=20 > > >>>>>>> I would like to secure a room for 2 days in total=20 > (9 to 5) in=20 > > >>>>>>> case we run long. > > >>>>>>> > > >>>>>>> At present, I think that everyone is available for=20 > the entire=20 > > >>>>>>> week, and so room availability could determine=20 > which two days=20 > > >>>>>>> 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=20 > know what you=20 > > >>>>>>> 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 > > >=20 > _______________________________________________ > FECFRAME-PROTO mailing list > FECFRAME-PROTO@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Sun Sep 16 01:19:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmXF-00086I-SN; Sun, 16 Sep 2007 01:19:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmXD-00086D-Nh for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:19:07 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWmXC-0001Qw-Ll for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:19:07 -0400 Received: from 68.167.206.145 ([68.167.206.145]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Sep 2007 05:20:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 15 Sep 2007 22:19:03 -0700 Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax From: Mark Watson To: "Ali Begen (abegen)" , Greg Shepherd , "mbany@dvblink.net" Message-ID: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Thread-Index: Acf4Hvsw1iXgof2RRx2mxnv87/OLQAAADPxAAAB6UNg= In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org My flight arrives 7.09, so all being well I guess I'll get to the Marriot 8-8.30. My cell is 415-867-6515. ...Mark On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: > My cell is 404-513-3694. > > I can join the dinner if it is going to be after 7:30pm. > > -acbegen > > > >> -----Original Message----- >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> Sent: Saturday, September 15, 2007 10:04 PM >> To: Michael Bany >> Cc: fecframe-proto@ietf.org >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >> >> I arrive late afternoon on Sunday. For those coming in Sunday >> who would like to get together for dinner, let's connect on >> the phone. My cell is: >> >> 541-915-4989 >> >> Greg >> >> On 9/13/07, Michael Bany wrote: >>> I am staying at the Marriot and I have a car. I won't arrive until >>> 11:30 pm though. >>> >>> I am going in and out of National. >>> >>> -----Original Message----- >>> From: Mark Watson [mailto:mark@digitalfountain.com] >>> Sent: Thursday, September 13, 2007 12:37 PM >>> To: Marshall Eubanks >>> Cc: fecframe-proto@ietf.org >>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting >> in Fairfax >>> >>> All, >>> >>> I am staying at the Marriott - is anyone else staying there and >>> planning to get a car ? If so then I'll just get taxis to/from the >>> airport. >>> >>> Anyone want to meet for a later dinner on Sunday ? I guess >> I'll get to >>> the hotel around 8-8.30. >>> >>> ...Mark >>> >>> >>> On 9/10/07 12:52 PM, "Marshall Eubanks" >> wrote: >>> >>>> >>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: >>>> >>>>> OK, I have called the >>>>> >>>>> Stafford House Bed & Breakfast >>>>> 3746 Chain Bridge Road >>>>> Fairfax, VA 22030 >>>> >>>> They have only 1 room available - a Suite with a King size bed. >>>> >>>> $ 159 for 1 person >>>> $ 179 for 2 (but you have to share the bed) >>>> >>>> Regards >>>> Marshall >>>> >>>>> >>>>> to see if they have any room - they are the only one >> close enough >>>>> to comfortably walk to GMU. I don't know if they are affordable, >>>>> though. >>>>> >>>>> None of the others have the slightest bit of charm - I would >>>>> recommend the >>>>> >>>>> Courtyard by Marriott - Fair Oaks >>>>> 11220 Lee Jackson Hwy. >>>>> Fairfax, VA 22030 >>>>> >>>>> It is easy to get to by car (just off I-66), and has bus >> ability too. >>>>> >>>>> Regards >>>>> Marshall >>>>> >>>>> P.S. If any one wants to stay at >>>>> Canary Cottage Bed & Breakfast >>>>> >>>>> ph: (703) 322-1811 >>>>> >>>>> 8.0 miles from Fairfax Campus >>>>> 7153 Main Street >>>>> Clifton, VA 20124 >>>>> >>>>> let me know - I live in Clifton and can give you a ride. >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Shiloh Dorgan >>>>>> Date: August 30, 2007 9:51:31 AM EDT >>>>>> To: Marshall Eubanks >>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen >> >>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax >>>>>> >>>>>> Here are the details:: >>>>>> >>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >>>>>> >>>>>> 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. >>>>>> >>>>>> Shiloh >>>>>> >>>>>> Marshall Eubanks 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 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Sun Sep 16 01:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmmC-0005gd-IP; Sun, 16 Sep 2007 01:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWmmA-0005fb-St for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:34:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWmm9-0002cT-HO for fecframe-proto@ietf.org; Sun, 16 Sep 2007 01:34:34 -0400 X-IronPort-AV: E=Sophos;i="4.20,259,1186383600"; d="scan'208";a="524360634" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2007 22:34:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8G5YWZC019292; Sat, 15 Sep 2007 22:34:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8G5YWVx011332; Sun, 16 Sep 2007 05:34:32 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 22:34:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Sat, 15 Sep 2007 22:34:29 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405264552@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax thread-index: Acf4Hvsw1iXgof2RRx2mxnv87/OLQAAADPxAAAB6UNgAAHaW0A== References: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> From: "Ali Begen \(abegen\)" To: "Mark Watson" , "Greg Shepherd" , X-OriginalArrivalTime: 16 Sep 2007 05:34:32.0367 (UTC) FILETIME=[4253A3F0:01C7F823] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11322; t=1189920872; x=1190784872; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Fwd=3A=20FECFRAME=20Design=20Meeti ng=20in=20Fairfax |Sender:=20; bh=F7U9afYsiLGj+oRgvGEBpp/3goLDM9mADlS0S4p2CDo=; b=oCfqoF3MqLVV9aCBOdTjUP61EonmqdcJxhcNj9gTlWqBXYai833v1LITEzYuyMzMNv3t0U98 vtQHTdVf0MH1QQl7HCyRzeLIhAxoMAhYagt7W9aC4YWe9XPZ0rgMBsvP; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org It looks it is going to be a late dinner, which is OK for me.=20 There are a couple of nice places around (I arrived Fairfax today afternoon...), which I believe are open until 11pm or so. -acbegen=20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Saturday, September 15, 2007 10:19 PM > To: Ali Begen (abegen); Greg Shepherd; mbany@dvblink.net > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > My flight arrives 7.09, so all being well I guess I'll get to=20 > the Marriot 8-8.30. My cell is 415-867-6515. >=20 > ...Mark >=20 >=20 > On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: >=20 > > My cell is 404-513-3694. > >=20 > > I can join the dinner if it is going to be after 7:30pm. > >=20 > > -acbegen > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Greg Shepherd [mailto:gjshep@gmail.com] > >> Sent: Saturday, September 15, 2007 10:04 PM > >> To: Michael Bany > >> Cc: fecframe-proto@ietf.org > >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting=20 > in Fairfax > >>=20 > >> I arrive late afternoon on Sunday. For those coming in Sunday who=20 > >> would like to get together for dinner, let's connect on=20 > the phone. My=20 > >> cell is: > >>=20 > >> 541-915-4989 > >>=20 > >> Greg > >>=20 > >> On 9/13/07, Michael Bany wrote: > >>> I am staying at the Marriot and I have a car. I won't=20 > arrive until=20 > >>> 11:30 pm though. > >>>=20 > >>> I am going in and out of National. > >>>=20 > >>> -----Original Message----- > >>> From: Mark Watson [mailto:mark@digitalfountain.com] > >>> Sent: Thursday, September 13, 2007 12:37 PM > >>> To: Marshall Eubanks > >>> Cc: fecframe-proto@ietf.org > >>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > >> in Fairfax > >>>=20 > >>> All, > >>>=20 > >>> I am staying at the Marriott - is anyone else staying there and=20 > >>> planning to get a car ? If so then I'll just get taxis=20 > to/from the=20 > >>> airport. > >>>=20 > >>> Anyone want to meet for a later dinner on Sunday ? I guess > >> I'll get to > >>> the hotel around 8-8.30. > >>>=20 > >>> ...Mark > >>>=20 > >>>=20 > >>> On 9/10/07 12:52 PM, "Marshall Eubanks" > >> wrote: > >>>=20 > >>>>=20 > >>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > >>>>=20 > >>>>> OK, I have called the > >>>>>=20 > >>>>> Stafford House Bed & Breakfast > >>>>> 3746 Chain Bridge Road > >>>>> Fairfax, VA 22030 > >>>>=20 > >>>> They have only 1 room available - a Suite with a King size bed. > >>>>=20 > >>>> $ 159 for 1 person > >>>> $ 179 for 2 (but you have to share the bed) > >>>>=20 > >>>> Regards > >>>> Marshall > >>>>=20 > >>>>>=20 > >>>>> to see if they have any room - they are the only one > >> close enough > >>>>> to comfortably walk to GMU. I don't know if they are=20 > affordable,=20 > >>>>> though. > >>>>>=20 > >>>>> None of the others have the slightest bit of charm - I would=20 > >>>>> recommend the > >>>>>=20 > >>>>> Courtyard by Marriott - Fair Oaks > >>>>> 11220 Lee Jackson Hwy. > >>>>> Fairfax, VA 22030 > >>>>>=20 > >>>>> It is easy to get to by car (just off I-66), and has bus > >> ability too. > >>>>>=20 > >>>>> Regards > >>>>> Marshall > >>>>>=20 > >>>>> P.S. If any one wants to stay at > >>>>> Canary Cottage Bed & Breakfast > >>>>>=20 > >>>>> ph: (703) 322-1811 > >>>>>=20 > >>>>> 8.0 miles from Fairfax Campus > >>>>> 7153 Main Street > >>>>> Clifton, VA 20124 > >>>>>=20 > >>>>> let me know - I live in Clifton and can give you a ride. > >>>>>=20 > >>>>>=20 > >>>>> Begin forwarded message: > >>>>>=20 > >>>>>> From: Shiloh Dorgan > >>>>>> Date: August 30, 2007 9:51:31 AM EDT > >>>>>> To: Marshall Eubanks > >>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen > >> > >>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax > >>>>>>=20 > >>>>>> Here are the details:: > >>>>>>=20 > >>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > >>>>>>=20 > >>>>>> 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=20 > Science &=20 > >>>>>> 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=20 > >>>>>> your right will be the conference room, room 320. > >>>>>>=20 > >>>>>> Shiloh > >>>>>>=20 > >>>>>> Marshall Eubanks 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. > >>>>>>>=20 > >>>>>>> Mark, Shiloh, can you recommend a nearby hotel ? > >>>>>>>=20 > >>>>>>> Also, we will need directions to the exact site of=20 > the meeting. > >>>>>>>=20 > >>>>>>> Travel arrangements : > >>>>>>>=20 > >>>>>>> Either Dulles (IAD) or National (DCA) airports have > >> easy access > >>>>>>> to GMU in Fairfax, Virginia. > >>>>>>>=20 > >>>>>>> National even has subway (Metro) access - > >>>>>>>=20 > >>>>>>> http://www.wmata.com/metrorail/systemmap.cfm > >>>>>>>=20 > >>>>>>> Blue line to the Orange line, Orange line to Vienna, a > >> short cab > >>>>>>> ride or CUE bus ride to GMU. > >>>>>>>=20 > >>>>>>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp > >>>>>>>=20 > >>>>>>> I would allow at least an hour for this. A cab ride > >> from National > >>>>>>> or Dulles will cost order $ 30, maybe more from Dulles. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> http://coyote.gmu.edu/map/fairfax.html > >>>>>>>=20 > >>>>>>> Baltimore Washington (BWI) is also possible but is a=20 > 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=20 > the flights=20 > >>>>>>> are really cheap. > >>>>>>>=20 > >>>>>>> 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=20 > >>>>>>> little traffic on Sunday. > >>>>>>>=20 > >>>>>>> If people come in early enough Sunday night we should > >> have dinner. > >>>>>>>=20 > >>>>>>> Regards > >>>>>>> Marshall > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: > >>>>>>>=20 > >>>>>>>> Room 320 is reserved for the FECFRAME meeting 17-18=20 > September. > >>>>>>>> Parking is $8/day. Let me know if anyone needs links for=20 > >>>>>>>> directions or has any questions. > >>>>>>>>=20 > >>>>>>>> Shiloh > >>>>>>>>=20 > >>>>>>>> Mark Pullen wrote: > >>>>>>>>> Marshall, > >>>>>>>>>=20 > >>>>>>>>> I'm happy to sponsor the meeting 17-18 Sep, on one=20 > 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=20 > >>>>>>>>> participants will need to pay ($7/day if it has not=20 > gone up)=20 > >>>>>>>>> for parking. They should use the parking desk and pay there. > >>>>>>>>> The alternative is public transport- the=20 > Fairfax/GMU CUE bus=20 > >>>>>>>>> provides an inexpensive shuttle to Vienna Metro and > >> area hotels > >>>>>>>>> (see www.gmu.edu for info). > >>>>>>>>>=20 > >>>>>>>>> Assuming the above is OK, I'm asking Shiloh to > >> reserve a room > >>>>>>>>> for you (Shiloh, start with 320 ST2 if available). > >>>>>>>>>=20 > >>>>>>>>> Mark > >>>>>>>>>=20 > >>>>>>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: > >>>>>>>>>=20 > >>>>>>>>>> Dear Mark; > >>>>>>>>>>=20 > >>>>>>>>>> I am trying to find a place for a design team > >> meeting for the > >>>>>>>>>> Fecframe IETF working group. > >>>>>>>>>>=20 > >>>>>>>>>> Fecframe is a new working group with a charter to > >>>>>>>>>>=20 > >>>>>>>>>> ...develop specifications for using forward error > >> correction > >>>>>>>>>> (FEC) codes with applications in the Internet to provide=20 > >>>>>>>>>> protection against packet loss. The group will develop a=20 > >>>>>>>>>> protocol framework for application of FEC codes to > >> arbitrary > >>>>>>>>>> packet flows over unreliable transport protocols > >> over both IP > >>>>>>>>>> multicast and unicast. > >>>>>>>>>>=20 > >>>>>>>>>> This has the potential to become an essential piece of=20 > >>>>>>>>>> technology underpinning IPTV. > >>>>>>>>>>=20 > >>>>>>>>>> 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. > >>>>>>>>>>=20 > >>>>>>>>>> At present, I think that everyone is available for > >> the entire > >>>>>>>>>> week, and so room availability could determine > >> which two days > >>>>>>>>>> we meet. > >>>>>>>>>>=20 > >>>>>>>>>> Do you think that there is any chance we could=20 > meet at GMU ? > >>>>>>>>>> Basically, we would need a > >>>>>>>>>> conference room or classroom for 2 days. Let me > >> know what you > >>>>>>>>>> think. > >>>>>>>>>>=20 > >>>>>>>>>> Regards > >>>>>>>>>> Marshall > >>>>>>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> FECFRAME-PROTO mailing list > >>>>> FECFRAME-PROTO@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> FECFRAME-PROTO mailing list > >>>> FECFRAME-PROTO@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>=20 > >> _______________________________________________ > >> FECFRAME-PROTO mailing list > >> FECFRAME-PROTO@ietf.org > >> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Sun Sep 16 09:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWuLk-00045k-SY; Sun, 16 Sep 2007 09:39:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWuLi-00045Y-Vg for fecframe-proto@ietf.org; Sun, 16 Sep 2007 09:39:47 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWuLh-00012R-T5 for fecframe-proto@ietf.org; Sun, 16 Sep 2007 09:39:46 -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 8441074; Sun, 16 Sep 2007 09:39:43 -0400 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405264552@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D5405264552@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75DE720C-D953-483F-BA72-68FC4784758B@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Sun, 16 Sep 2007 09:39:33 -0400 To: "Ali Begen \(abegen\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On Sep 16, 2007, at 1:34 AM, Ali Begen ((abegen)) wrote: > It looks it is going to be a late dinner, which is OK for me. > > There are a couple of nice places around (I arrived Fairfax today > afternoon...), which I believe are open until 11pm or so. Not so much on Sunday night, it gets tough after 10:00 PM. If all else fails, the Amphora is open 24 hours (go North on 123 until you get to Vienna, it will be on the left just after Nutley). It's got all sorts of conventional food and some Greek fare. Regards Marshall > > -acbegen > >> -----Original Message----- >> From: Mark Watson [mailto:mark@digitalfountain.com] >> Sent: Saturday, September 15, 2007 10:19 PM >> To: Ali Begen (abegen); Greg Shepherd; mbany@dvblink.net >> Cc: fecframe-proto@ietf.org >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >> >> My flight arrives 7.09, so all being well I guess I'll get to >> the Marriot 8-8.30. My cell is 415-867-6515. >> >> ...Mark >> >> >> On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: >> >>> My cell is 404-513-3694. >>> >>> I can join the dinner if it is going to be after 7:30pm. >>> >>> -acbegen >>> >>> >>> >>>> -----Original Message----- >>>> From: Greg Shepherd [mailto:gjshep@gmail.com] >>>> Sent: Saturday, September 15, 2007 10:04 PM >>>> To: Michael Bany >>>> Cc: fecframe-proto@ietf.org >>>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting >> in Fairfax >>>> >>>> I arrive late afternoon on Sunday. For those coming in Sunday who >>>> would like to get together for dinner, let's connect on >> the phone. My >>>> cell is: >>>> >>>> 541-915-4989 >>>> >>>> Greg >>>> >>>> On 9/13/07, Michael Bany wrote: >>>>> I am staying at the Marriot and I have a car. I won't >> arrive until >>>>> 11:30 pm though. >>>>> >>>>> I am going in and out of National. >>>>> >>>>> -----Original Message----- >>>>> From: Mark Watson [mailto:mark@digitalfountain.com] >>>>> Sent: Thursday, September 13, 2007 12:37 PM >>>>> To: Marshall Eubanks >>>>> Cc: fecframe-proto@ietf.org >>>>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting >>>> in Fairfax >>>>> >>>>> All, >>>>> >>>>> I am staying at the Marriott - is anyone else staying there and >>>>> planning to get a car ? If so then I'll just get taxis >> to/from the >>>>> airport. >>>>> >>>>> Anyone want to meet for a later dinner on Sunday ? I guess >>>> I'll get to >>>>> the hotel around 8-8.30. >>>>> >>>>> ...Mark >>>>> >>>>> >>>>> On 9/10/07 12:52 PM, "Marshall Eubanks" >>>> wrote: >>>>> >>>>>> >>>>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: >>>>>> >>>>>>> OK, I have called the >>>>>>> >>>>>>> Stafford House Bed & Breakfast >>>>>>> 3746 Chain Bridge Road >>>>>>> Fairfax, VA 22030 >>>>>> >>>>>> They have only 1 room available - a Suite with a King size bed. >>>>>> >>>>>> $ 159 for 1 person >>>>>> $ 179 for 2 (but you have to share the bed) >>>>>> >>>>>> Regards >>>>>> Marshall >>>>>> >>>>>>> >>>>>>> to see if they have any room - they are the only one >>>> close enough >>>>>>> to comfortably walk to GMU. I don't know if they are >> affordable, >>>>>>> though. >>>>>>> >>>>>>> None of the others have the slightest bit of charm - I would >>>>>>> recommend the >>>>>>> >>>>>>> Courtyard by Marriott - Fair Oaks >>>>>>> 11220 Lee Jackson Hwy. >>>>>>> Fairfax, VA 22030 >>>>>>> >>>>>>> It is easy to get to by car (just off I-66), and has bus >>>> ability too. >>>>>>> >>>>>>> Regards >>>>>>> Marshall >>>>>>> >>>>>>> P.S. If any one wants to stay at >>>>>>> Canary Cottage Bed & Breakfast >>>>>>> >>>>>>> ph: (703) 322-1811 >>>>>>> >>>>>>> 8.0 miles from Fairfax Campus >>>>>>> 7153 Main Street >>>>>>> Clifton, VA 20124 >>>>>>> >>>>>>> let me know - I live in Clifton and can give you a ride. >>>>>>> >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Shiloh Dorgan >>>>>>>> Date: August 30, 2007 9:51:31 AM EDT >>>>>>>> To: Marshall Eubanks >>>>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen >>>> >>>>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax >>>>>>>> >>>>>>>> Here are the details:: >>>>>>>> >>>>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> Shiloh >>>>>>>> >>>>>>>> Marshall Eubanks 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 >> > > _______________________________________________ > 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 From fecframe-proto-bounces@ietf.org Sun Sep 16 17:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX1Gz-0000b3-Px; Sun, 16 Sep 2007 17:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX1Gy-0000ay-Qf for fecframe-proto@ietf.org; Sun, 16 Sep 2007 17:03:20 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX1Gx-0004KV-Ap for fecframe-proto@ietf.org; Sun, 16 Sep 2007 17:03:20 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2346412wah for ; Sun, 16 Sep 2007 14:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=T9GEmy+bAjhCV5Bc71N4gcfhyJxjcb2+jBxBnihzheY=; b=ieTLxpjiTeZQpTxHahUb/MdrjNOcBBQDE85W6LL2YkOzyeKWdCCW3/pHPotqpMDMW1bjPr+bZpYvfLFlk8VMUPBYXSGtemp6RsXx2zZiKr6NdJ3Pze923AHoGxzrJQ5uBoO/U13MoZoOVt+KJowlngyJide2TwpTCWvM8+yUNSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U6TOMdY/jdkMNVwHDcK3O6xAxWidLjK80xh90cBLHg9kKfsWZ46/0KPMmASktasfSWsoNnE1+4RhBnOLwNF90jsRlQnsh54gvlC6wFmrell9jT7MYTrtEn5O1USLTa2yXFrW7Rvidk4srGh4SCyTUoVRc0ISu1OJSsihcW6ZAzY= Received: by 10.115.46.9 with SMTP id y9mr2289974waj.1189976598196; Sun, 16 Sep 2007 14:03:18 -0700 (PDT) Received: by 10.114.132.18 with HTTP; Sun, 16 Sep 2007 14:03:18 -0700 (PDT) Message-ID: <38c19b540709161403p68aa64dl4d612b85362d4f4c@mail.gmail.com> Date: Sun, 16 Sep 2007 14:03:18 -0700 From: "Greg Shepherd" To: "Marshall Eubanks" Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax In-Reply-To: <75DE720C-D953-483F-BA72-68FC4784758B@multicasttech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D5405264552@xmb-sjc-215.amer.cisco.com> <75DE720C-D953-483F-BA72-68FC4784758B@multicasttech.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Grim news from me... I picked-up an infection last week in India which apparently has not been fully eradicated. It seems to have returned yesterday. I got up this morning with the intention of making the flight to DC but decided it was not the right thing to do considering my current condition. I've spoken with Marshall and he's going to try to secure access in our room at GW so as to vid-conference me in for the duration of the meeting - so I'll be there in the form of a TV-head. Sorry for this last-minute change on my part but I'm confident we'll progress despite my absence - or perhaps because of my absence. ;-) Thank you for your understanding. Let's hope I can shake this bug for good. Greg On 9/16/07, Marshall Eubanks wrote: > > On Sep 16, 2007, at 1:34 AM, Ali Begen ((abegen)) wrote: > > > It looks it is going to be a late dinner, which is OK for me. > > > > There are a couple of nice places around (I arrived Fairfax today > > afternoon...), which I believe are open until 11pm or so. > > Not so much on Sunday night, it gets tough after 10:00 PM. If all > else fails, the Amphora is open 24 hours (go North on 123 until you > get to Vienna, it will be on the left just after Nutley). It's got > all sorts of conventional food and some Greek fare. > > Regards > Marshall > > > > > -acbegen > > > >> -----Original Message----- > >> From: Mark Watson [mailto:mark@digitalfountain.com] > >> Sent: Saturday, September 15, 2007 10:19 PM > >> To: Ali Begen (abegen); Greg Shepherd; mbany@dvblink.net > >> Cc: fecframe-proto@ietf.org > >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > >> > >> My flight arrives 7.09, so all being well I guess I'll get to > >> the Marriot 8-8.30. My cell is 415-867-6515. > >> > >> ...Mark > >> > >> > >> On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: > >> > >>> My cell is 404-513-3694. > >>> > >>> I can join the dinner if it is going to be after 7:30pm. > >>> > >>> -acbegen > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > >>>> Sent: Saturday, September 15, 2007 10:04 PM > >>>> To: Michael Bany > >>>> Cc: fecframe-proto@ietf.org > >>>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > >> in Fairfax > >>>> > >>>> I arrive late afternoon on Sunday. For those coming in Sunday who > >>>> would like to get together for dinner, let's connect on > >> the phone. My > >>>> cell is: > >>>> > >>>> 541-915-4989 > >>>> > >>>> Greg > >>>> > >>>> On 9/13/07, Michael Bany wrote: > >>>>> I am staying at the Marriot and I have a car. I won't > >> arrive until > >>>>> 11:30 pm though. > >>>>> > >>>>> I am going in and out of National. > >>>>> > >>>>> -----Original Message----- > >>>>> From: Mark Watson [mailto:mark@digitalfountain.com] > >>>>> Sent: Thursday, September 13, 2007 12:37 PM > >>>>> To: Marshall Eubanks > >>>>> Cc: fecframe-proto@ietf.org > >>>>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > >>>> in Fairfax > >>>>> > >>>>> All, > >>>>> > >>>>> I am staying at the Marriott - is anyone else staying there and > >>>>> planning to get a car ? If so then I'll just get taxis > >> to/from the > >>>>> airport. > >>>>> > >>>>> Anyone want to meet for a later dinner on Sunday ? I guess > >>>> I'll get to > >>>>> the hotel around 8-8.30. > >>>>> > >>>>> ...Mark > >>>>> > >>>>> > >>>>> On 9/10/07 12:52 PM, "Marshall Eubanks" > >>>> wrote: > >>>>> > >>>>>> > >>>>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > >>>>>> > >>>>>>> OK, I have called the > >>>>>>> > >>>>>>> Stafford House Bed & Breakfast > >>>>>>> 3746 Chain Bridge Road > >>>>>>> Fairfax, VA 22030 > >>>>>> > >>>>>> They have only 1 room available - a Suite with a King size bed. > >>>>>> > >>>>>> $ 159 for 1 person > >>>>>> $ 179 for 2 (but you have to share the bed) > >>>>>> > >>>>>> Regards > >>>>>> Marshall > >>>>>> > >>>>>>> > >>>>>>> to see if they have any room - they are the only one > >>>> close enough > >>>>>>> to comfortably walk to GMU. I don't know if they are > >> affordable, > >>>>>>> though. > >>>>>>> > >>>>>>> None of the others have the slightest bit of charm - I would > >>>>>>> recommend the > >>>>>>> > >>>>>>> Courtyard by Marriott - Fair Oaks > >>>>>>> 11220 Lee Jackson Hwy. > >>>>>>> Fairfax, VA 22030 > >>>>>>> > >>>>>>> It is easy to get to by car (just off I-66), and has bus > >>>> ability too. > >>>>>>> > >>>>>>> Regards > >>>>>>> Marshall > >>>>>>> > >>>>>>> P.S. If any one wants to stay at > >>>>>>> Canary Cottage Bed & Breakfast > >>>>>>> > >>>>>>> ph: (703) 322-1811 > >>>>>>> > >>>>>>> 8.0 miles from Fairfax Campus > >>>>>>> 7153 Main Street > >>>>>>> Clifton, VA 20124 > >>>>>>> > >>>>>>> let me know - I live in Clifton and can give you a ride. > >>>>>>> > >>>>>>> > >>>>>>> Begin forwarded message: > >>>>>>> > >>>>>>>> From: Shiloh Dorgan > >>>>>>>> Date: August 30, 2007 9:51:31 AM EDT > >>>>>>>> To: Marshall Eubanks > >>>>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen > >>>> > >>>>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax > >>>>>>>> > >>>>>>>> Here are the details:: > >>>>>>>> > >>>>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > >>>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> Shiloh > >>>>>>>> > >>>>>>>> Marshall Eubanks 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 > >> > > > > _______________________________________________ > > 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 From fecframe-proto-bounces@ietf.org Mon Sep 17 01:19:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX90j-00034x-OF; Mon, 17 Sep 2007 01:19:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX90h-000332-5o for fecframe-proto@ietf.org; Mon, 17 Sep 2007 01:19:03 -0400 Received: from www.amesweb.com ([216.218.233.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX90f-0000rk-Aw for fecframe-proto@ietf.org; Mon, 17 Sep 2007 01:19:02 -0400 Received: from exchange.amesweb.com ([12.215.108.10]) by www.amesweb.com with esmtp (Exim 4.10) id 1IX90e-0000Wt-00 for fecframe-proto@ietf.org; Mon, 17 Sep 2007 00:19:00 -0500 Content-class: urn:content-classes:message Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Sep 2007 00:18:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Thread-Index: Acf4Hvsw1iXgof2RRx2mxnv87/OLQAAADPxAAAB6UNgAMkNt8A== References: <04CAD96D4C5A3D48B1919248A8FE0D5405264550@xmb-sjc-215.amer.cisco.com> From: "Michael Bany" To: "Mark Watson" , "Ali Begen (abegen)" , "Greg Shepherd" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I forgot to add my Cell number is 319-533-8003. It sounds like we meet at the Marriott between 8 and 8:30. -----Original Message----- From: Mark Watson [mailto:mark@digitalfountain.com]=20 Sent: Sunday, September 16, 2007 12:19 AM To: Ali Begen (abegen); Greg Shepherd; Michael Bany Cc: fecframe-proto@ietf.org Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax My flight arrives 7.09, so all being well I guess I'll get to the Marriot 8-8.30. My cell is 415-867-6515. ...Mark On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: > My cell is 404-513-3694. >=20 > I can join the dinner if it is going to be after 7:30pm. >=20 > -acbegen >=20 >=20 >=20 >> -----Original Message----- >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> Sent: Saturday, September 15, 2007 10:04 PM >> To: Michael Bany >> Cc: fecframe-proto@ietf.org >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >>=20 >> I arrive late afternoon on Sunday. For those coming in Sunday >> who would like to get together for dinner, let's connect on >> the phone. My cell is: >>=20 >> 541-915-4989 >>=20 >> Greg >>=20 >> On 9/13/07, Michael Bany wrote: >>> I am staying at the Marriot and I have a car. I won't arrive until >>> 11:30 pm though. >>>=20 >>> I am going in and out of National. >>>=20 >>> -----Original Message----- >>> From: Mark Watson [mailto:mark@digitalfountain.com] >>> Sent: Thursday, September 13, 2007 12:37 PM >>> To: Marshall Eubanks >>> Cc: fecframe-proto@ietf.org >>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting >> in Fairfax >>>=20 >>> All, >>>=20 >>> I am staying at the Marriott - is anyone else staying there and >>> planning to get a car ? If so then I'll just get taxis to/from the >>> airport. >>>=20 >>> Anyone want to meet for a later dinner on Sunday ? I guess >> I'll get to=20 >>> the hotel around 8-8.30. >>>=20 >>> ...Mark >>>=20 >>>=20 >>> On 9/10/07 12:52 PM, "Marshall Eubanks" >> wrote: >>>=20 >>>>=20 >>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: >>>>=20 >>>>> OK, I have called the >>>>>=20 >>>>> Stafford House Bed & Breakfast >>>>> 3746 Chain Bridge Road >>>>> Fairfax, VA 22030 >>>>=20 >>>> They have only 1 room available - a Suite with a King size bed. >>>>=20 >>>> $ 159 for 1 person >>>> $ 179 for 2 (but you have to share the bed) >>>>=20 >>>> Regards >>>> Marshall >>>>=20 >>>>>=20 >>>>> to see if they have any room - they are the only one >> close enough=20 >>>>> to comfortably walk to GMU. I don't know if they are affordable, >>>>> though. >>>>>=20 >>>>> None of the others have the slightest bit of charm - I would >>>>> recommend the >>>>>=20 >>>>> Courtyard by Marriott - Fair Oaks >>>>> 11220 Lee Jackson Hwy. >>>>> Fairfax, VA 22030 >>>>>=20 >>>>> It is easy to get to by car (just off I-66), and has bus >> ability too. >>>>>=20 >>>>> Regards >>>>> Marshall >>>>>=20 >>>>> P.S. If any one wants to stay at >>>>> Canary Cottage Bed & Breakfast >>>>>=20 >>>>> ph: (703) 322-1811 >>>>>=20 >>>>> 8.0 miles from Fairfax Campus >>>>> 7153 Main Street >>>>> Clifton, VA 20124 >>>>>=20 >>>>> let me know - I live in Clifton and can give you a ride. >>>>>=20 >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: Shiloh Dorgan >>>>>> Date: August 30, 2007 9:51:31 AM EDT >>>>>> To: Marshall Eubanks >>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen >> >>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax >>>>>>=20 >>>>>> Here are the details:: >>>>>>=20 >>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX >>>>>>=20 >>>>>> 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=20 >>>>>> floor, turn left, go to the end of the hall, turn right and on >>>>>> your right will be the conference room, room 320. >>>>>>=20 >>>>>> Shiloh >>>>>>=20 >>>>>> Marshall Eubanks wrote: >>>>>>> OK, having waited for the dust to settle, and having >> polled the=20 >>>>>>> members who wanted the other dates, the Design team >> meeting will=20 >>>>>>> be at George Mason University 17-18 September. Our >> thanks to GMU=20 >>>>>>> for offering the space. >>>>>>>=20 >>>>>>> Mark, Shiloh, can you recommend a nearby hotel ? >>>>>>>=20 >>>>>>> Also, we will need directions to the exact site of the meeting. >>>>>>>=20 >>>>>>> Travel arrangements : >>>>>>>=20 >>>>>>> Either Dulles (IAD) or National (DCA) airports have >> easy access=20 >>>>>>> to GMU in Fairfax, Virginia. >>>>>>>=20 >>>>>>> National even has subway (Metro) access - >>>>>>>=20 >>>>>>> http://www.wmata.com/metrorail/systemmap.cfm >>>>>>>=20 >>>>>>> Blue line to the Orange line, Orange line to Vienna, a >> short cab=20 >>>>>>> ride or CUE bus ride to GMU. >>>>>>>=20 >>>>>>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp >>>>>>>=20 >>>>>>> I would allow at least an hour for this. A cab ride >> from National=20 >>>>>>> or Dulles will cost order $ 30, maybe more from Dulles. >>>>>>>=20 >>>>>>> If anyone does not plan to have a car, please let me >> know. I can=20 >>>>>>> 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=20 >>>>>>> have a car, but it is possible. The GMU campus itself >> is pretty=20 >>>>>>> spread out. >>>>>>>=20 >>>>>>> http://coyote.gmu.edu/map/fairfax.html >>>>>>>=20 >>>>>>> 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=20 >>>>>>> Washington itself. I would not recommend it unless the flights >>>>>>> are really cheap. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> If people come in early enough Sunday night we should >> have dinner. >>>>>>>=20 >>>>>>> Regards >>>>>>> Marshall >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: >>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Shiloh >>>>>>>>=20 >>>>>>>> Mark Pullen wrote: >>>>>>>>> Marshall, >>>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>> (see www.gmu.edu for info). >>>>>>>>>=20 >>>>>>>>> Assuming the above is OK, I'm asking Shiloh to >> reserve a room=20 >>>>>>>>> for you (Shiloh, start with 320 ST2 if available). >>>>>>>>>=20 >>>>>>>>> Mark >>>>>>>>>=20 >>>>>>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: >>>>>>>>>=20 >>>>>>>>>> Dear Mark; >>>>>>>>>>=20 >>>>>>>>>> I am trying to find a place for a design team >> meeting for the=20 >>>>>>>>>> Fecframe IETF working group. >>>>>>>>>>=20 >>>>>>>>>> Fecframe is a new working group with a charter to >>>>>>>>>>=20 >>>>>>>>>> ...develop specifications for using forward error >> correction=20 >>>>>>>>>> (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=20 >>>>>>>>>> packet flows over unreliable transport protocols >> over both IP=20 >>>>>>>>>> multicast and unicast. >>>>>>>>>>=20 >>>>>>>>>> This has the potential to become an essential piece of >>>>>>>>>> technology underpinning IPTV. >>>>>>>>>>=20 >>>>>>>>>> We need to have a meeting of the design team (6 >> people), and=20 >>>>>>>>>> have settled on the week of September 17th. We >> estimate that=20 >>>>>>>>>> this will require the use of a room for a day and a >> half, but=20 >>>>>>>>>> I would like to secure a room for 2 days in total >> (9 to 5) in=20 >>>>>>>>>> case we run long. >>>>>>>>>>=20 >>>>>>>>>> At present, I think that everyone is available for >> the entire=20 >>>>>>>>>> week, and so room availability could determine >> which two days=20 >>>>>>>>>> we meet. >>>>>>>>>>=20 >>>>>>>>>> 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=20 >>>>>>>>>> think. >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>> Marshall >>>>>>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> FECFRAME-PROTO mailing list >>>>> FECFRAME-PROTO@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> FECFRAME-PROTO mailing list >>>> FECFRAME-PROTO@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto >>>=20 >>>=20 >>> _______________________________________________ >>> FECFRAME-PROTO mailing list >>> FECFRAME-PROTO@ietf.org >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto >>>=20 >>> _______________________________________________ >>> FECFRAME-PROTO mailing list >>> FECFRAME-PROTO@ietf.org >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto >>>=20 >>=20 >> _______________________________________________ >> FECFRAME-PROTO mailing list >> FECFRAME-PROTO@ietf.org >> https://www1.ietf.org/mailman/listinfo/fecframe-proto >>=20 >=20 > _______________________________________________ > 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 From fecframe-proto-bounces@ietf.org Mon Sep 17 08:02:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFJC-0003AL-93; Mon, 17 Sep 2007 08:02:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFJA-00038G-4o for fecframe-proto@ietf.org; Mon, 17 Sep 2007 08:02:32 -0400 Received: from www.amesweb.com ([216.218.233.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXFJ8-0004Qj-0F for fecframe-proto@ietf.org; Mon, 17 Sep 2007 08:02:31 -0400 Received: from exchange.amesweb.com ([12.215.108.10]) by www.amesweb.com with esmtp (Exim 4.10) id 1IXFJ6-0002XA-00 for fecframe-proto@ietf.org; Mon, 17 Sep 2007 07:02:28 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Sep 2007 07:02:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Thread-Index: Acf5IagWrSh9ICKiRROuDqNYwPzfywAAPTW3 From: "Michael Bany" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0880860162==" Errors-To: fecframe-proto-bounces@ietf.org --===============0880860162== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhbSBhdCB0aGUgTWFycmlvdHQuICBJIGhhdmUgYSBjYXIgYnV0IEknbSBub3QgdG90YWxseSBz dXJlIGhvdyB0byBnZXQgdGhlcmUuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IG1hcmtAZGlnaXRhbGZvdW50YWluLmNvbSA8bWFya0BkaWdpdGFsZm91bnRhaW4uY29tPg0K VG86IE1pY2hhZWwgQmFueTsgQWxpIEJlZ2VuIChhYmVnZW4pIDxhYmVnZW5AY2lzY28uY29tPjsg R3JlZyBTaGVwaGVyZCA8Z2pzaGVwQGdtYWlsLmNvbT4NCkNjOiBmZWNmcmFtZS1wcm90b0BpZXRm Lm9yZyA8ZmVjZnJhbWUtcHJvdG9AaWV0Zi5vcmc+DQpTZW50OiBNb24gU2VwIDE3IDA2OjU1OjE1 IDIwMDcNClN1YmplY3Q6IFJlOiBbRkVDRlJBTUUtUFJPVE9dIEZ3ZDogRkVDRlJBTUUgRGVzaWdu IE1lZXRpbmcgaW4gRmFpcmZheA0KDQpJIHRoaW5rIEdNVSBhdCA5LiA4LTguMzAgd2FzIGZvciBs YXN0IG5pZ2h0LiBBbGkgaXMgY29sbGVjdGluZyBtZSBmcm9tIHRoZSBNYXJyaW90dCBhdCA4LjMw LCBzaW5jZSBJIGRvbid0IGhhdmUgYSBjYXIsIGJ1dCB0aGUgcGxhbiBpcyB0byBnbyBzdHJhaWd0 eSB0byBHTVUuDQoNCi4uLk1hcmsNClNlbnQgdmlhIEJsYWNrQmVycnkgZnJvbSBULU1vYmlsZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIk1pY2hhZWwgQmFueSIgPG1iYW55 QGR2YmxpbmsubmV0Pg0KDQpEYXRlOiBNb24sIDE3IFNlcCAyMDA3IDAwOjE4OjUwIA0KVG86Ik1h cmsgV2F0c29uIiA8bWFya0BkaWdpdGFsZm91bnRhaW4uY29tPiwiQWxpIEJlZ2VuIFwoYWJlZ2Vu XCkiIDxhYmVnZW5AY2lzY28uY29tPiwiR3JlZyBTaGVwaGVyZCIgPGdqc2hlcEBnbWFpbC5jb20+ DQpDYzo8ZmVjZnJhbWUtcHJvdG9AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0ZFQ0ZSQU1FLVBS T1RPXSBGd2Q6IEZFQ0ZSQU1FIERlc2lnbiBNZWV0aW5nIGluIEZhaXJmYXgNCg0KDQpJIGZvcmdv dCB0byBhZGQgbXkgQ2VsbCBudW1iZXIgaXMgMzE5LTUzMy04MDAzLg0KDQpJdCBzb3VuZHMgbGlr ZSB3ZSBtZWV0IGF0IHRoZSBNYXJyaW90dCBiZXR3ZWVuIDggYW5kIDg6MzAuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJrIFdhdHNvbiBbbWFpbHRvOm1hcmtAZGlnaXRh bGZvdW50YWluLmNvbV0gDQpTZW50OiBTdW5kYXksIFNlcHRlbWJlciAxNiwgMjAwNyAxMjoxOSBB TQ0KVG86IEFsaSBCZWdlbiAoYWJlZ2VuKTsgR3JlZyBTaGVwaGVyZDsgTWljaGFlbCBCYW55DQpD YzogZmVjZnJhbWUtcHJvdG9AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRkVDRlJBTUUtUFJPVE9d IEZ3ZDogRkVDRlJBTUUgRGVzaWduIE1lZXRpbmcgaW4gRmFpcmZheA0KDQpNeSBmbGlnaHQgYXJy aXZlcyA3LjA5LCBzbyBhbGwgYmVpbmcgd2VsbCBJIGd1ZXNzIEknbGwgZ2V0IHRvIHRoZQ0KTWFy cmlvdA0KOC04LjMwLiBNeSBjZWxsIGlzIDQxNS04NjctNjUxNS4NCg0KLi4uTWFyaw0KDQoNCk9u IDkvMTUvMDcgMTA6MDcgUE0sICJBbGkgQmVnZW4gKGFiZWdlbikiIDxhYmVnZW5AY2lzY28uY29t PiB3cm90ZToNCg0KPiBNeSBjZWxsIGlzIDQwNC01MTMtMzY5NC4NCj4gDQo+IEkgY2FuIGpvaW4g dGhlIGRpbm5lciBpZiBpdCBpcyBnb2luZyB0byBiZSBhZnRlciA3OjMwcG0uDQo+IA0KPiAtYWNi ZWdlbg0KPiANCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IEdyZWcgU2hlcGhlcmQgW21haWx0bzpnanNoZXBAZ21haWwuY29tXQ0KPj4gU2VudDogU2F0dXJk YXksIFNlcHRlbWJlciAxNSwgMjAwNyAxMDowNCBQTQ0KPj4gVG86IE1pY2hhZWwgQmFueQ0KPj4g Q2M6IGZlY2ZyYW1lLXByb3RvQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW0ZFQ0ZSQU1FLVBS T1RPXSBGd2Q6IEZFQ0ZSQU1FIERlc2lnbiBNZWV0aW5nIGluIEZhaXJmYXgNCj4+IA0KPj4gSSBh cnJpdmUgbGF0ZSBhZnRlcm5vb24gb24gU3VuZGF5LiBGb3IgdGhvc2UgY29taW5nIGluIFN1bmRh eQ0KPj4gd2hvIHdvdWxkIGxpa2UgdG8gZ2V0IHRvZ2V0aGVyIGZvciBkaW5uZXIsIGxldCdzIGNv bm5lY3Qgb24NCj4+IHRoZSBwaG9uZS4gTXkgY2VsbCBpczoNCj4+IA0KPj4gNTQxLTkxNS00OTg5 DQo+PiANCj4+IEdyZWcNCj4+IA0KPj4gT24gOS8xMy8wNywgTWljaGFlbCBCYW55IDxtYmFueUBk dmJsaW5rLm5ldD4gd3JvdGU6DQo+Pj4gSSBhbSBzdGF5aW5nIGF0IHRoZSBNYXJyaW90IGFuZCBJ IGhhdmUgYSBjYXIuICBJIHdvbid0IGFycml2ZSB1bnRpbA0KPj4+IDExOjMwIHBtIHRob3VnaC4N Cj4+PiANCj4+PiBJIGFtIGdvaW5nIGluIGFuZCBvdXQgb2YgTmF0aW9uYWwuDQo+Pj4gDQo+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBNYXJrIFdhdHNvbiBbbWFpbHRv Om1hcmtAZGlnaXRhbGZvdW50YWluLmNvbV0NCj4+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVy IDEzLCAyMDA3IDEyOjM3IFBNDQo+Pj4gVG86IE1hcnNoYWxsIEV1YmFua3MNCj4+PiBDYzogZmVj ZnJhbWUtcHJvdG9AaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW0ZFQ0ZSQU1FLVBST1RPXSBG d2Q6IEZFQ0ZSQU1FIERlc2lnbiBNZWV0aW5nDQo+PiBpbiBGYWlyZmF4DQo+Pj4gDQo+Pj4gQWxs LA0KPj4+IA0KPj4+IEkgYW0gc3RheWluZyBhdCB0aGUgTWFycmlvdHQgLSBpcyBhbnlvbmUgZWxz ZSBzdGF5aW5nIHRoZXJlIGFuZA0KPj4+IHBsYW5uaW5nIHRvIGdldCBhIGNhciA/IElmIHNvIHRo ZW4gSSdsbCBqdXN0IGdldCB0YXhpcyB0by9mcm9tIHRoZQ0KPj4+IGFpcnBvcnQuDQo+Pj4gDQo+ Pj4gQW55b25lIHdhbnQgdG8gbWVldCBmb3IgYSBsYXRlciBkaW5uZXIgb24gU3VuZGF5ID8gSSBn dWVzcw0KPj4gSSdsbCBnZXQgdG8gDQo+Pj4gdGhlIGhvdGVsIGFyb3VuZCA4LTguMzAuDQo+Pj4g DQo+Pj4gLi4uTWFyaw0KPj4+IA0KPj4+IA0KPj4+IE9uIDkvMTAvMDcgMTI6NTIgUE0sICJNYXJz aGFsbCBFdWJhbmtzIg0KPj4gPHRtZUBtdWx0aWNhc3R0ZWNoLmNvbT4gd3JvdGU6DQo+Pj4gDQo+ Pj4+IA0KPj4+PiBPbiBTZXAgMTAsIDIwMDcsIGF0IDE6MjIgUE0sIE1hcnNoYWxsIEV1YmFua3Mg d3JvdGU6DQo+Pj4+IA0KPj4+Pj4gT0ssIEkgaGF2ZSBjYWxsZWQgdGhlDQo+Pj4+PiANCj4+Pj4+ IFN0YWZmb3JkIEhvdXNlIEJlZCAmIEJyZWFrZmFzdA0KPj4+Pj4gMzc0NiBDaGFpbiBCcmlkZ2Ug Um9hZA0KPj4+Pj4gRmFpcmZheCwgVkEgIDIyMDMwDQo+Pj4+IA0KPj4+PiBUaGV5IGhhdmUgb25s eSAxIHJvb20gYXZhaWxhYmxlIC0gYSBTdWl0ZSB3aXRoIGEgS2luZyBzaXplIGJlZC4NCj4+Pj4g DQo+Pj4+ICQgMTU5IGZvciAxIHBlcnNvbg0KPj4+PiAkIDE3OSBmb3IgMiAoYnV0IHlvdSBoYXZl IHRvIHNoYXJlIHRoZSBiZWQpDQo+Pj4+IA0KPj4+PiBSZWdhcmRzDQo+Pj4+IE1hcnNoYWxsDQo+ Pj4+IA0KPj4+Pj4gDQo+Pj4+PiB0byBzZWUgaWYgdGhleSBoYXZlIGFueSByb29tIC0gdGhleSBh cmUgdGhlIG9ubHkgb25lDQo+PiBjbG9zZSBlbm91Z2ggDQo+Pj4+PiB0byBjb21mb3J0YWJseSB3 YWxrIHRvIEdNVS4gSSBkb24ndCBrbm93IGlmIHRoZXkgYXJlIGFmZm9yZGFibGUsDQo+Pj4+PiB0 aG91Z2guDQo+Pj4+PiANCj4+Pj4+IE5vbmUgb2YgdGhlIG90aGVycyBoYXZlIHRoZSBzbGlnaHRl c3QgYml0IG9mIGNoYXJtIC0gSSB3b3VsZA0KPj4+Pj4gcmVjb21tZW5kIHRoZQ0KPj4+Pj4gDQo+ Pj4+PiBDb3VydHlhcmQgYnkgTWFycmlvdHQgLSBGYWlyIE9ha3MNCj4+Pj4+IDExMjIwIExlZSBK YWNrc29uIEh3eS4NCj4+Pj4+IEZhaXJmYXgsIFZBICAyMjAzMA0KPj4+Pj4gDQo+Pj4+PiBJdCBp cyBlYXN5IHRvIGdldCB0byBieSBjYXIgKGp1c3Qgb2ZmIEktNjYpLCBhbmQgaGFzIGJ1cw0KPj4g YWJpbGl0eSB0b28uDQo+Pj4+PiANCj4+Pj4+IFJlZ2FyZHMNCj4+Pj4+IE1hcnNoYWxsDQo+Pj4+ PiANCj4+Pj4+IFAuUy4gSWYgYW55IG9uZSB3YW50cyB0byBzdGF5IGF0DQo+Pj4+PiBDYW5hcnkg Q290dGFnZSBCZWQgJiBCcmVha2Zhc3QNCj4+Pj4+IA0KPj4+Pj4gcGg6ICg3MDMpIDMyMi0xODEx DQo+Pj4+PiANCj4+Pj4+IDguMCBtaWxlcyBmcm9tIEZhaXJmYXggQ2FtcHVzDQo+Pj4+PiA3MTUz IE1haW4gU3RyZWV0DQo+Pj4+PiBDbGlmdG9uLCBWQSAgMjAxMjQNCj4+Pj4+IA0KPj4+Pj4gbGV0 IG1lIGtub3cgLSBJIGxpdmUgaW4gQ2xpZnRvbiBhbmQgY2FuIGdpdmUgeW91IGEgcmlkZS4NCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+Pj4+IA0KPj4+ Pj4+IEZyb206IFNoaWxvaCBEb3JnYW4gPHNkb3JnYW5AYzRpLmdtdS5lZHU+DQo+Pj4+Pj4gRGF0 ZTogQXVndXN0IDMwLCAyMDA3IDk6NTE6MzEgQU0gRURUDQo+Pj4+Pj4gVG86IE1hcnNoYWxsIEV1 YmFua3MgPHRtZUBtdWx0aWNhc3R0ZWNoLmNvbT4NCj4+Pj4+PiBDYzogZmVjZnJhbWUtcHJvdG9A aWV0Zi5vcmcsIE1hcmsgUHVsbGVuDQo+PiA8bXB1bGxlbkBuZXRsYWIuZ211LmVkdT4NCj4+Pj4+ PiBTdWJqZWN0OiBSZTogRkVDRlJBTUUgRGVzaWduIE1lZXRpbmcgaW4gRmFpcmZheA0KPj4+Pj4+ IA0KPj4+Pj4+IEhlcmUgYXJlIHRoZSBkZXRhaWxzOjoNCj4+Pj4+PiANCj4+Pj4+PiBBcmVhIGhv dGVsczogaHR0cDovL3d3dy5nbXUuZWR1L3dlbGNvbWUvaG90ZWwuaHRtbCNGQUlSRkFYDQo+Pj4+ Pj4gDQo+Pj4+Pj4gRGlyZWN0aW9ucyB0byBtZWV0aW5nIGxvY2F0aW9uIChTY2llbmNlICYgVGVj aG5vbG9neSBJSQ0KPj4gYmxkZywgcm9vbQ0KPj4+Pj4+IDMyMCk6DQo+Pj4+Pj4gUGFyayBpbiB0 aGUgU2FuZHkgQ3JlZWsgcGFya2luZyBkZWNrOg0KPj4gaHR0cDovL2NveW90ZS5nbXUuZWR1L21h cC8NCj4+Pj4+PiBtYXBodG1sL3BhcmtpbmdkZWNrMi5odG1sIFdhbGsgYWNyb3NzIHRoZSByb2Fk IHRvIHRoZSBTY2llbmNlICYNCj4+Pj4+PiBUZWNobm9sb2d5IElJIGJsZGcsIGl0IGlzIHdpdGhp biB2aWV3IGZyb20gdGhlIHBhcmtpbmcgZGVjazoNCj4+Pj4+PiBodHRwOi8vY295b3RlLmdtdS5l ZHUvbWFwLyBtYXBodG1sL3N0MjEuaHRtbCBFbGV2YXRvcg0KPj4gdG8gdGhlIHRoaXJkIA0KPj4+ Pj4+IGZsb29yLCB0dXJuIGxlZnQsIGdvIHRvIHRoZSBlbmQgb2YgdGhlIGhhbGwsIHR1cm4gcmln aHQgYW5kIG9uDQo+Pj4+Pj4geW91ciByaWdodCB3aWxsIGJlIHRoZSBjb25mZXJlbmNlIHJvb20s IHJvb20gMzIwLg0KPj4+Pj4+IA0KPj4+Pj4+IFNoaWxvaA0KPj4+Pj4+IA0KPj4+Pj4+IE1hcnNo YWxsIEV1YmFua3Mgd3JvdGU6DQo+Pj4+Pj4+IE9LLCBoYXZpbmcgd2FpdGVkIGZvciB0aGUgZHVz dCB0byBzZXR0bGUsIGFuZCBoYXZpbmcNCj4+IHBvbGxlZCB0aGUgDQo+Pj4+Pj4+IG1lbWJlcnMg d2hvIHdhbnRlZCB0aGUgb3RoZXIgZGF0ZXMsIHRoZSBEZXNpZ24gdGVhbQ0KPj4gbWVldGluZyB3 aWxsIA0KPj4+Pj4+PiBiZSBhdCBHZW9yZ2UgTWFzb24gVW5pdmVyc2l0eSAxNy0xOCBTZXB0ZW1i ZXIuIE91cg0KPj4gdGhhbmtzIHRvIEdNVSANCj4+Pj4+Pj4gZm9yIG9mZmVyaW5nIHRoZSBzcGFj ZS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE1hcmssIFNoaWxvaCwgY2FuIHlvdSByZWNvbW1lbmQgYSBu ZWFyYnkgaG90ZWwgPw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQWxzbywgd2Ugd2lsbCBuZWVkIGRpcmVj dGlvbnMgdG8gdGhlIGV4YWN0IHNpdGUgb2YgdGhlIG1lZXRpbmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBUcmF2ZWwgYXJyYW5nZW1lbnRzIDoNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEVpdGhlciBEdWxsZXMg KElBRCkgb3IgTmF0aW9uYWwgKERDQSkgYWlycG9ydHMgaGF2ZQ0KPj4gZWFzeSBhY2Nlc3MgDQo+ Pj4+Pj4+IHRvIEdNVSBpbiBGYWlyZmF4LCBWaXJnaW5pYS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE5h dGlvbmFsIGV2ZW4gaGFzIHN1YndheSAoTWV0cm8pIGFjY2VzcyAtDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBodHRwOi8vd3d3LndtYXRhLmNvbS9tZXRyb3JhaWwvc3lzdGVtbWFwLmNmbQ0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gQmx1ZSBsaW5lIHRvIHRoZSBPcmFuZ2UgbGluZSwgT3JhbmdlIGxpbmUgdG8gVmll bm5hLCBhDQo+PiBzaG9ydCBjYWIgDQo+Pj4+Pj4+IHJpZGUgb3IgQ1VFIGJ1cyByaWRlIHRvIEdN VS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGh0dHA6Ly93d3cuZmFpcmZheHZhLmdvdi9DVUVCdXMvQ1VF QnVzLmFzcA0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSB3b3VsZCBhbGxvdyBhdCBsZWFzdCBhbiBob3Vy IGZvciB0aGlzLiBBIGNhYiByaWRlDQo+PiBmcm9tIE5hdGlvbmFsIA0KPj4+Pj4+PiBvciBEdWxs ZXMgd2lsbCBjb3N0IG9yZGVyICQgMzAsIG1heWJlIG1vcmUgZnJvbSBEdWxsZXMuDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBJZiBhbnlvbmUgZG9lcyBub3QgcGxhbiB0byBoYXZlIGEgY2FyLCBwbGVhc2Ug bGV0IG1lDQo+PiBrbm93LiBJIGNhbiANCj4+Pj4+Pj4gcGljayB1cCBhIGxpbWl0ZWQgbnVtYmVy IG9yIHBlb3BsZSBvbiB0aGUgd2F5IGluIGVhY2ggbW9ybmluZy4NCj4+Pj4+Pj4gTGlrZSBtYW55 IEFtZXJpY2FuIHN1YnVyYnMsIHlvdSB3aWxsIGZlZWwgbGltaXRlZCBpZg0KPj4geW91IGRvIG5v dCANCj4+Pj4+Pj4gaGF2ZSBhIGNhciwgYnV0IGl0IGlzIHBvc3NpYmxlLiBUaGUgR01VIGNhbXB1 cyBpdHNlbGYNCj4+IGlzIHByZXR0eSANCj4+Pj4+Pj4gc3ByZWFkIG91dC4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IGh0dHA6Ly9jb3lvdGUuZ211LmVkdS9tYXAvZmFpcmZheC5odG1sDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBCYWx0aW1vcmUgV2FzaGluZ3RvbiAoQldJKSBpcyBhbHNvIHBvc3NpYmxlIGJ1dCBp cyBhIGdvb2QgMSBhbmQNCj4+Pj4+Pj4gMS8yIGhvdXIgZHJpdmUgYXdheSBhdCBiZXN0IGFuZCB5 b3UgaGF2ZSB0byBnbyB0aHJvdWdoDQo+PiBvciBhcm91bmQgDQo+Pj4+Pj4+IFdhc2hpbmd0b24g aXRzZWxmLiBJIHdvdWxkIG5vdCByZWNvbW1lbmQgaXQgdW5sZXNzIHRoZSBmbGlnaHRzDQo+Pj4+ Pj4+IGFyZSByZWFsbHkgY2hlYXAuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgQmUgd2FybmVkIHRoYXQg REMgaGFzIGEgdmVyeSBzdHJvbmcgYW5kIHR5cGljYWwgcnVzaCAiaG91ciINCj4+Pj4+Pj4gKH42 OjMwIHRvIDk6MDAgQU0sIH40OjAwIHRvIDc6MDAgUE0pLiBUaGVyZSB3aWxsIHByb2JhYmx5IGJl DQo+Pj4+Pj4+IGxpdHRsZSB0cmFmZmljIG9uIFN1bmRheS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IElm IHBlb3BsZSBjb21lIGluIGVhcmx5IGVub3VnaCBTdW5kYXkgbmlnaHQgd2Ugc2hvdWxkDQo+PiBo YXZlIGRpbm5lci4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFJlZ2FyZHMNCj4+Pj4+Pj4gTWFyc2hhbGwN Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIEF1ZyAy MiwgMjAwNywgYXQgNzozMCBBTSwgU2hpbG9oIERvcmdhbiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBSb29tIDMyMCBpcyByZXNlcnZlZCBmb3IgdGhlIEZFQ0ZSQU1FIG1lZXRpbmcgMTctMTgg U2VwdGVtYmVyLg0KPj4+Pj4+Pj4gUGFya2luZyBpcyAkOC9kYXkuIExldCBtZSBrbm93IGlmIGFu eW9uZSBuZWVkcyBsaW5rcyBmb3INCj4+Pj4+Pj4+IGRpcmVjdGlvbnMgb3IgaGFzIGFueSBxdWVz dGlvbnMuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFNoaWxvaA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBN YXJrIFB1bGxlbiB3cm90ZToNCj4+Pj4+Pj4+PiBNYXJzaGFsbCwNCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBJJ20gaGFwcHkgdG8gc3BvbnNvciB0aGUgbWVldGluZyAxNy0xOCBTZXAsIG9uIG9uZSBj b25kaXRpb246DQo+Pj4+Pj4+Pj4gSSBtdXN0IGJlIGFibGUgdG8gaW52aXRlIG15IHN0dWRlbnRz IHRvIGxpc3RlbiBpbi4gQWxzbyB5b3UNCj4+PiBzaG91bGQNCj4+Pj4+Pj4+PiBrbm93IHRoYXQg d2hpbGUgdGhlIHJvb20gd2lsbCBiZSBwcm92aWRlZCBhdCBubyBjb3N0LCB0aGUNCj4+Pj4+Pj4+ PiBwYXJ0aWNpcGFudHMgd2lsbCBuZWVkIHRvIHBheSAoJDcvZGF5IGlmIGl0IGhhcyBub3QgZ29u ZSB1cCkNCj4+Pj4+Pj4+PiBmb3IgcGFya2luZy4gVGhleSBzaG91bGQgdXNlIHRoZSBwYXJraW5n IGRlc2sgYW5kIHBheSB0aGVyZS4NCj4+Pj4+Pj4+PiBUaGUgYWx0ZXJuYXRpdmUgaXMgcHVibGlj IHRyYW5zcG9ydC0gdGhlIEZhaXJmYXgvR01VIENVRSBidXMNCj4+Pj4+Pj4+PiBwcm92aWRlcyBh biBpbmV4cGVuc2l2ZSBzaHV0dGxlIHRvIFZpZW5uYSBNZXRybyBhbmQNCj4+IGFyZWEgaG90ZWxz IA0KPj4+Pj4+Pj4+IChzZWUgd3d3LmdtdS5lZHUgZm9yIGluZm8pLg0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IEFzc3VtaW5nIHRoZSBhYm92ZSBpcyBPSywgSSdtIGFza2luZyBTaGlsb2ggdG8NCj4+ IHJlc2VydmUgYSByb29tIA0KPj4+Pj4+Pj4+IGZvciB5b3UgKFNoaWxvaCwgc3RhcnQgd2l0aCAz MjAgU1QyIGlmIGF2YWlsYWJsZSkuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTWFyaw0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IE9uIFN1biwgMTkgQXVnIDIwMDcsIE1hcnNoYWxsIEV1YmFua3Mgd3Jv dGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IERlYXIgTWFyazsNCj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+IEkgYW0gdHJ5aW5nIHRvIGZpbmQgYSBwbGFjZSBmb3IgYSBkZXNpZ24gdGVhbQ0KPj4g bWVldGluZyBmb3IgdGhlIA0KPj4+Pj4+Pj4+PiBGZWNmcmFtZSBJRVRGIHdvcmtpbmcgZ3JvdXAu DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBGZWNmcmFtZSBpcyBhIG5ldyB3b3JraW5nIGdyb3Vw IHdpdGggYSBjaGFydGVyIHRvDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAuLi5kZXZlbG9wIHNw ZWNpZmljYXRpb25zIGZvciB1c2luZyBmb3J3YXJkIGVycm9yDQo+PiBjb3JyZWN0aW9uIA0KPj4+ Pj4+Pj4+PiAoRkVDKSBjb2RlcyB3aXRoIGFwcGxpY2F0aW9ucyBpbiB0aGUgSW50ZXJuZXQgdG8g cHJvdmlkZQ0KPj4+Pj4+Pj4+PiBwcm90ZWN0aW9uIGFnYWluc3QgcGFja2V0IGxvc3MuIFRoZSBn cm91cCB3aWxsIGRldmVsb3AgYQ0KPj4+Pj4+Pj4+PiBwcm90b2NvbCBmcmFtZXdvcmsgZm9yIGFw cGxpY2F0aW9uIG9mIEZFQyBjb2RlcyB0bw0KPj4gYXJiaXRyYXJ5IA0KPj4+Pj4+Pj4+PiBwYWNr ZXQgZmxvd3Mgb3ZlciB1bnJlbGlhYmxlIHRyYW5zcG9ydCBwcm90b2NvbHMNCj4+IG92ZXIgYm90 aCBJUCANCj4+Pj4+Pj4+Pj4gbXVsdGljYXN0IGFuZCB1bmljYXN0Lg0KPj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4gVGhpcyBoYXMgdGhlIHBvdGVudGlhbCB0byBiZWNvbWUgYW4gZXNzZW50aWFsIHBp ZWNlIG9mDQo+Pj4+Pj4+Pj4+IHRlY2hub2xvZ3kgdW5kZXJwaW5uaW5nIElQVFYuDQo+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+PiBXZSBuZWVkIHRvIGhhdmUgYSBtZWV0aW5nIG9mIHRoZSBkZXNpZ24g dGVhbSAoNg0KPj4gcGVvcGxlKSwgYW5kIA0KPj4+Pj4+Pj4+PiBoYXZlIHNldHRsZWQgb24gdGhl IHdlZWsgb2YgU2VwdGVtYmVyIDE3dGguIFdlDQo+PiBlc3RpbWF0ZSB0aGF0IA0KPj4+Pj4+Pj4+ PiB0aGlzIHdpbGwgcmVxdWlyZSB0aGUgdXNlIG9mIGEgcm9vbSBmb3IgYSBkYXkgYW5kIGENCj4+ IGhhbGYsIGJ1dCANCj4+Pj4+Pj4+Pj4gSSB3b3VsZCBsaWtlIHRvIHNlY3VyZSBhIHJvb20gZm9y IDIgZGF5cyBpbiB0b3RhbA0KPj4gKDkgdG8gNSkgaW4gDQo+Pj4+Pj4+Pj4+IGNhc2Ugd2UgcnVu IGxvbmcuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBBdCBwcmVzZW50LCBJIHRoaW5rIHRoYXQg ZXZlcnlvbmUgaXMgYXZhaWxhYmxlIGZvcg0KPj4gdGhlIGVudGlyZSANCj4+Pj4+Pj4+Pj4gd2Vl aywgYW5kIHNvIHJvb20gYXZhaWxhYmlsaXR5IGNvdWxkIGRldGVybWluZQ0KPj4gd2hpY2ggdHdv IGRheXMgDQo+Pj4+Pj4+Pj4+IHdlIG1lZXQuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBEbyB5 b3UgdGhpbmsgdGhhdCB0aGVyZSBpcyBhbnkgY2hhbmNlIHdlIGNvdWxkIG1lZXQgYXQgR01VID8N Cj4+Pj4+Pj4+Pj4gQmFzaWNhbGx5LCB3ZSB3b3VsZCBuZWVkIGENCj4+Pj4+Pj4+Pj4gY29uZmVy ZW5jZSByb29tIG9yIGNsYXNzcm9vbSBmb3IgMiBkYXlzLiBMZXQgbWUNCj4+IGtub3cgd2hhdCB5 b3UgDQo+Pj4+Pj4+Pj4+IHRoaW5rLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gUmVnYXJkcw0K Pj4+Pj4+Pj4+PiBNYXJzaGFsbA0KPj4+Pj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBGRUNG UkFNRS1QUk9UTyBtYWlsaW5nIGxpc3QNCj4+Pj4+IEZFQ0ZSQU1FLVBST1RPQGlldGYub3JnDQo+ Pj4+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZWNmcmFtZS1wcm90 bw0KPj4+PiANCj4+Pj4gDQo+Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gRkVDRlJBTUUtUFJPVE8gbWFpbGluZyBsaXN0DQo+Pj4+IEZFQ0ZS QU1FLVBST1RPQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZlY2ZyYW1lLXByb3RvDQo+Pj4gDQo+Pj4gDQo+Pj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEZFQ0ZSQU1FLVBST1RPIG1haWxpbmcg bGlzdA0KPj4+IEZFQ0ZSQU1FLVBST1RPQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWUtcHJvdG8NCj4+PiANCj4+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gRkVDRlJBTUUtUFJPVE8g bWFpbGluZyBsaXN0DQo+Pj4gRkVDRlJBTUUtUFJPVE9AaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZWNmcmFtZS1wcm90bw0KPj4+IA0KPj4gDQo+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBGRUNG UkFNRS1QUk9UTyBtYWlsaW5nIGxpc3QNCj4+IEZFQ0ZSQU1FLVBST1RPQGlldGYub3JnDQo+PiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZWNmcmFtZS1wcm90bw0KPj4g DQo+IA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEZFQ0ZSQU1FLVBST1RPIG1haWxpbmcgbGlzdA0KPiBGRUNGUkFNRS1QUk9UT0BpZXRmLm9yZw0K PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZWNmcmFtZS1wcm90bw0K DQo= --===============0880860162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto --===============0880860162==-- From fecframe-proto-bounces@ietf.org Mon Sep 17 08:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFdN-0003Gy-Au; Mon, 17 Sep 2007 08:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFdM-0003Gn-FB for fecframe-proto@ietf.org; Mon, 17 Sep 2007 08:23:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXFdL-0002V1-0c for fecframe-proto@ietf.org; Mon, 17 Sep 2007 08:23:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,264,1186383600"; d="scan'208";a="399450980" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Sep 2007 05:23:19 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8HCNI3C016505; Mon, 17 Sep 2007 05:23:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8HCNEus009047; Mon, 17 Sep 2007 12:23:14 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 05:23:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax Date: Mon, 17 Sep 2007 05:23:07 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405264635@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax thread-index: Acf5IagWrSh9ICKiRROuDqNYwPzfywAAPTW3AACuB4A= References: From: "Ali Begen \(abegen\)" To: "Michael Bany" , , X-OriginalArrivalTime: 17 Sep 2007 12:23:13.0999 (UTC) FILETIME=[84C57DF0:01C7F925] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12689; t=1190031798; x=1190895798; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Fwd=3A=20FECFRAME=20Design=20Meeti ng=20in=20Fairfax |Sender:=20; bh=iMSzcm/vtZUPq32msj4w4lqadf6uGI4N0dv9dndlubc=; b=NFUrCjEzaH4XycDBmEp51i9A4yEsj8XALTnxeQPXQ7c2h3rXGmqglRGanVEbdtIk4Z3+z4Yv n3erxrW5yZDMHmeOPEJSwAI0+6I7I36FhdM1Xzk+7JOhRP4E/I3A9vQtxWW472MCjzgJzOgUWA +7sGEqmaUyGjrvF56zeB3Mxpw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Morning Michael, I will be at Mariott in 10 minutes. You can follow us, I got the directions. -acbegen=20 > -----Original Message----- > From: Michael Bany [mailto:mbany@dvblink.net]=20 > Sent: Monday, September 17, 2007 5:02 AM > To: mark@digitalfountain.com; Ali Begen (abegen); gjshep@gmail.com > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > I am at the Marriott. I have a car but I'm not totally sure=20 > how to get there. >=20 > ----- Original Message ----- > From: mark@digitalfountain.com > To: Michael Bany; Ali Begen (abegen) ; Greg=20 > Shepherd > Cc: fecframe-proto@ietf.org > Sent: Mon Sep 17 06:55:15 2007 > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > I think GMU at 9. 8-8.30 was for last night. Ali is=20 > collecting me from the Marriott at 8.30, since I don't have a=20 > car, but the plan is to go straigty to GMU. >=20 > ...Mark > Sent via BlackBerry from T-Mobile >=20 > -----Original Message----- > From: "Michael Bany" >=20 > Date: Mon, 17 Sep 2007 00:18:50 > To:"Mark Watson" ,"Ali Begen=20 > \(abegen\)" ,"Greg Shepherd"=20 > Cc: > Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 >=20 > I forgot to add my Cell number is 319-533-8003. >=20 > It sounds like we meet at the Marriott between 8 and 8:30. >=20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Sunday, September 16, 2007 12:19 AM > To: Ali Begen (abegen); Greg Shepherd; Michael Bany > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax >=20 > My flight arrives 7.09, so all being well I guess I'll get to the > Marriot > 8-8.30. My cell is 415-867-6515. >=20 > ...Mark >=20 >=20 > On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: >=20 > > My cell is 404-513-3694. > >=20 > > I can join the dinner if it is going to be after 7:30pm. > >=20 > > -acbegen > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Greg Shepherd [mailto:gjshep@gmail.com] > >> Sent: Saturday, September 15, 2007 10:04 PM > >> To: Michael Bany > >> Cc: fecframe-proto@ietf.org > >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting=20 > in Fairfax > >>=20 > >> I arrive late afternoon on Sunday. For those coming in Sunday > >> who would like to get together for dinner, let's connect on > >> the phone. My cell is: > >>=20 > >> 541-915-4989 > >>=20 > >> Greg > >>=20 > >> On 9/13/07, Michael Bany wrote: > >>> I am staying at the Marriot and I have a car. I won't=20 > arrive until > >>> 11:30 pm though. > >>>=20 > >>> I am going in and out of National. > >>>=20 > >>> -----Original Message----- > >>> From: Mark Watson [mailto:mark@digitalfountain.com] > >>> Sent: Thursday, September 13, 2007 12:37 PM > >>> To: Marshall Eubanks > >>> Cc: fecframe-proto@ietf.org > >>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > >> in Fairfax > >>>=20 > >>> All, > >>>=20 > >>> I am staying at the Marriott - is anyone else staying there and > >>> planning to get a car ? If so then I'll just get taxis to/from the > >>> airport. > >>>=20 > >>> Anyone want to meet for a later dinner on Sunday ? I guess > >> I'll get to=20 > >>> the hotel around 8-8.30. > >>>=20 > >>> ...Mark > >>>=20 > >>>=20 > >>> On 9/10/07 12:52 PM, "Marshall Eubanks" > >> wrote: > >>>=20 > >>>>=20 > >>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > >>>>=20 > >>>>> OK, I have called the > >>>>>=20 > >>>>> Stafford House Bed & Breakfast > >>>>> 3746 Chain Bridge Road > >>>>> Fairfax, VA 22030 > >>>>=20 > >>>> They have only 1 room available - a Suite with a King size bed. > >>>>=20 > >>>> $ 159 for 1 person > >>>> $ 179 for 2 (but you have to share the bed) > >>>>=20 > >>>> Regards > >>>> Marshall > >>>>=20 > >>>>>=20 > >>>>> to see if they have any room - they are the only one > >> close enough=20 > >>>>> to comfortably walk to GMU. I don't know if they are affordable, > >>>>> though. > >>>>>=20 > >>>>> None of the others have the slightest bit of charm - I would > >>>>> recommend the > >>>>>=20 > >>>>> Courtyard by Marriott - Fair Oaks > >>>>> 11220 Lee Jackson Hwy. > >>>>> Fairfax, VA 22030 > >>>>>=20 > >>>>> It is easy to get to by car (just off I-66), and has bus > >> ability too. > >>>>>=20 > >>>>> Regards > >>>>> Marshall > >>>>>=20 > >>>>> P.S. If any one wants to stay at > >>>>> Canary Cottage Bed & Breakfast > >>>>>=20 > >>>>> ph: (703) 322-1811 > >>>>>=20 > >>>>> 8.0 miles from Fairfax Campus > >>>>> 7153 Main Street > >>>>> Clifton, VA 20124 > >>>>>=20 > >>>>> let me know - I live in Clifton and can give you a ride. > >>>>>=20 > >>>>>=20 > >>>>> Begin forwarded message: > >>>>>=20 > >>>>>> From: Shiloh Dorgan > >>>>>> Date: August 30, 2007 9:51:31 AM EDT > >>>>>> To: Marshall Eubanks > >>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen > >> > >>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax > >>>>>>=20 > >>>>>> Here are the details:: > >>>>>>=20 > >>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > >>>>>>=20 > >>>>>> 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=20 > >>>>>> floor, turn left, go to the end of the hall, turn right and on > >>>>>> your right will be the conference room, room 320. > >>>>>>=20 > >>>>>> Shiloh > >>>>>>=20 > >>>>>> Marshall Eubanks wrote: > >>>>>>> OK, having waited for the dust to settle, and having > >> polled the=20 > >>>>>>> members who wanted the other dates, the Design team > >> meeting will=20 > >>>>>>> be at George Mason University 17-18 September. Our > >> thanks to GMU=20 > >>>>>>> for offering the space. > >>>>>>>=20 > >>>>>>> Mark, Shiloh, can you recommend a nearby hotel ? > >>>>>>>=20 > >>>>>>> Also, we will need directions to the exact site of=20 > the meeting. > >>>>>>>=20 > >>>>>>> Travel arrangements : > >>>>>>>=20 > >>>>>>> Either Dulles (IAD) or National (DCA) airports have > >> easy access=20 > >>>>>>> to GMU in Fairfax, Virginia. > >>>>>>>=20 > >>>>>>> National even has subway (Metro) access - > >>>>>>>=20 > >>>>>>> http://www.wmata.com/metrorail/systemmap.cfm > >>>>>>>=20 > >>>>>>> Blue line to the Orange line, Orange line to Vienna, a > >> short cab=20 > >>>>>>> ride or CUE bus ride to GMU. > >>>>>>>=20 > >>>>>>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp > >>>>>>>=20 > >>>>>>> I would allow at least an hour for this. A cab ride > >> from National=20 > >>>>>>> or Dulles will cost order $ 30, maybe more from Dulles. > >>>>>>>=20 > >>>>>>> If anyone does not plan to have a car, please let me > >> know. I can=20 > >>>>>>> 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=20 > >>>>>>> have a car, but it is possible. The GMU campus itself > >> is pretty=20 > >>>>>>> spread out. > >>>>>>>=20 > >>>>>>> http://coyote.gmu.edu/map/fairfax.html > >>>>>>>=20 > >>>>>>> Baltimore Washington (BWI) is also possible but is a=20 > good 1 and > >>>>>>> 1/2 hour drive away at best and you have to go through > >> or around=20 > >>>>>>> Washington itself. I would not recommend it unless the flights > >>>>>>> are really cheap. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> If people come in early enough Sunday night we should > >> have dinner. > >>>>>>>=20 > >>>>>>> Regards > >>>>>>> Marshall > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: > >>>>>>>=20 > >>>>>>>> Room 320 is reserved for the FECFRAME meeting 17-18=20 > September. > >>>>>>>> Parking is $8/day. Let me know if anyone needs links for > >>>>>>>> directions or has any questions. > >>>>>>>>=20 > >>>>>>>> Shiloh > >>>>>>>>=20 > >>>>>>>> Mark Pullen wrote: > >>>>>>>>> Marshall, > >>>>>>>>>=20 > >>>>>>>>> I'm happy to sponsor the meeting 17-18 Sep, on one=20 > 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=20 > >>>>>>>>> (see www.gmu.edu for info). > >>>>>>>>>=20 > >>>>>>>>> Assuming the above is OK, I'm asking Shiloh to > >> reserve a room=20 > >>>>>>>>> for you (Shiloh, start with 320 ST2 if available). > >>>>>>>>>=20 > >>>>>>>>> Mark > >>>>>>>>>=20 > >>>>>>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: > >>>>>>>>>=20 > >>>>>>>>>> Dear Mark; > >>>>>>>>>>=20 > >>>>>>>>>> I am trying to find a place for a design team > >> meeting for the=20 > >>>>>>>>>> Fecframe IETF working group. > >>>>>>>>>>=20 > >>>>>>>>>> Fecframe is a new working group with a charter to > >>>>>>>>>>=20 > >>>>>>>>>> ...develop specifications for using forward error > >> correction=20 > >>>>>>>>>> (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=20 > >>>>>>>>>> packet flows over unreliable transport protocols > >> over both IP=20 > >>>>>>>>>> multicast and unicast. > >>>>>>>>>>=20 > >>>>>>>>>> This has the potential to become an essential piece of > >>>>>>>>>> technology underpinning IPTV. > >>>>>>>>>>=20 > >>>>>>>>>> We need to have a meeting of the design team (6 > >> people), and=20 > >>>>>>>>>> have settled on the week of September 17th. We > >> estimate that=20 > >>>>>>>>>> this will require the use of a room for a day and a > >> half, but=20 > >>>>>>>>>> I would like to secure a room for 2 days in total > >> (9 to 5) in=20 > >>>>>>>>>> case we run long. > >>>>>>>>>>=20 > >>>>>>>>>> At present, I think that everyone is available for > >> the entire=20 > >>>>>>>>>> week, and so room availability could determine > >> which two days=20 > >>>>>>>>>> we meet. > >>>>>>>>>>=20 > >>>>>>>>>> Do you think that there is any chance we could=20 > meet at GMU ? > >>>>>>>>>> Basically, we would need a > >>>>>>>>>> conference room or classroom for 2 days. Let me > >> know what you=20 > >>>>>>>>>> think. > >>>>>>>>>>=20 > >>>>>>>>>> Regards > >>>>>>>>>> Marshall > >>>>>>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>_______________________________________________ > >>>>> FECFRAME-PROTO mailing list > >>>>> FECFRAME-PROTO@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>>=20 > >>>>=20 > >>>>_______________________________________________ > >>>> FECFRAME-PROTO mailing list > >>>> FECFRAME-PROTO@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>>=20 > >>>_______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>>_______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>=20 > >>_______________________________________________ > >> FECFRAME-PROTO mailing list > >> FECFRAME-PROTO@ietf.org > >> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>=20 > >=20 > >_______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Tue Sep 18 09:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXd4H-0005VD-TS; Tue, 18 Sep 2007 09:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXd4G-0005TZ-7z for fecframe-proto@ietf.org; Tue, 18 Sep 2007 09:24:44 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXd49-0006ty-PC for fecframe-proto@ietf.org; Tue, 18 Sep 2007 09:24:44 -0400 Received: by wa-out-1112.google.com with SMTP id k40so3225992wah for ; Tue, 18 Sep 2007 06:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=p0QdLzsQ/Nfy0vpGam8JQnAM5DHs8CPZstlXGf3BtkU=; b=rDYcTOXvREljqJf6R+aQyltgSRlmIo2TjXwrRBU62cCvcH1lVGDZGp88ftrlJEvSxgz3cbmUR6vJeBC4miRKcyavfOQG/zV1AdR2tcvU0OgKjk+A9Xla7rXbPbOhoPujJjr5J/KDEkjGfQR1F3RfvQgMK3BAis8qX8zYRNoWZ0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hhyIn9piwxJuH+2ZXKDPNaOOIn6N4FZqGkfyH2tq1HI1mKvyRuXNLpI1NvVT7bIkAImC4k281/VgrY0CXXFHvnzbe2knv2ctpNQ9DRkPsqvFNcxQ93kRlo3wA7l2L14TIRRR6ok7bEiLEmi8o188OCW53N687qliTWaWtS3tvZw= Received: by 10.115.95.1 with SMTP id x1mr1062805wal.1190121854712; Tue, 18 Sep 2007 06:24:14 -0700 (PDT) Received: by 10.114.132.13 with HTTP; Tue, 18 Sep 2007 06:24:14 -0700 (PDT) Message-ID: <38c19b540709180624q1238e085g18686eb866ebc689@mail.gmail.com> Date: Tue, 18 Sep 2007 06:24:14 -0700 From: "Greg Shepherd" To: "Ali Begen (abegen)" Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405264635@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5405264635@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Good morning. iChat is up but I don't see Marshall online yet. Ping me when you're ready to start this morning. Greg On 9/17/07, Ali Begen (abegen) wrote: > Morning Michael, > > I will be at Mariott in 10 minutes. You can follow us, I got the > directions. > > -acbegen > > > > -----Original Message----- > > From: Michael Bany [mailto:mbany@dvblink.net] > > Sent: Monday, September 17, 2007 5:02 AM > > To: mark@digitalfountain.com; Ali Begen (abegen); gjshep@gmail.com > > Cc: fecframe-proto@ietf.org > > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > > > I am at the Marriott. I have a car but I'm not totally sure > > how to get there. > > > > ----- Original Message ----- > > From: mark@digitalfountain.com > > To: Michael Bany; Ali Begen (abegen) ; Greg > > Shepherd > > Cc: fecframe-proto@ietf.org > > Sent: Mon Sep 17 06:55:15 2007 > > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > > > I think GMU at 9. 8-8.30 was for last night. Ali is > > collecting me from the Marriott at 8.30, since I don't have a > > car, but the plan is to go straigty to GMU. > > > > ...Mark > > Sent via BlackBerry from T-Mobile > > > > -----Original Message----- > > From: "Michael Bany" > > > > Date: Mon, 17 Sep 2007 00:18:50 > > To:"Mark Watson" ,"Ali Begen > > \(abegen\)" ,"Greg Shepherd" > > Cc: > > Subject: RE: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > > > > > I forgot to add my Cell number is 319-533-8003. > > > > It sounds like we meet at the Marriott between 8 and 8:30. > > > > -----Original Message----- > > From: Mark Watson [mailto:mark@digitalfountain.com] > > Sent: Sunday, September 16, 2007 12:19 AM > > To: Ali Begen (abegen); Greg Shepherd; Michael Bany > > Cc: fecframe-proto@ietf.org > > Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting in Fairfax > > > > My flight arrives 7.09, so all being well I guess I'll get to the > > Marriot > > 8-8.30. My cell is 415-867-6515. > > > > ...Mark > > > > > > On 9/15/07 10:07 PM, "Ali Begen (abegen)" wrote: > > > > > My cell is 404-513-3694. > > > > > > I can join the dinner if it is going to be after 7:30pm. > > > > > > -acbegen > > > > > > > > > > > >> -----Original Message----- > > >> From: Greg Shepherd [mailto:gjshep@gmail.com] > > >> Sent: Saturday, September 15, 2007 10:04 PM > > >> To: Michael Bany > > >> Cc: fecframe-proto@ietf.org > > >> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > > in Fairfax > > >> > > >> I arrive late afternoon on Sunday. For those coming in Sunday > > >> who would like to get together for dinner, let's connect on > > >> the phone. My cell is: > > >> > > >> 541-915-4989 > > >> > > >> Greg > > >> > > >> On 9/13/07, Michael Bany wrote: > > >>> I am staying at the Marriot and I have a car. I won't > > arrive until > > >>> 11:30 pm though. > > >>> > > >>> I am going in and out of National. > > >>> > > >>> -----Original Message----- > > >>> From: Mark Watson [mailto:mark@digitalfountain.com] > > >>> Sent: Thursday, September 13, 2007 12:37 PM > > >>> To: Marshall Eubanks > > >>> Cc: fecframe-proto@ietf.org > > >>> Subject: Re: [FECFRAME-PROTO] Fwd: FECFRAME Design Meeting > > >> in Fairfax > > >>> > > >>> All, > > >>> > > >>> I am staying at the Marriott - is anyone else staying there and > > >>> planning to get a car ? If so then I'll just get taxis to/from the > > >>> airport. > > >>> > > >>> Anyone want to meet for a later dinner on Sunday ? I guess > > >> I'll get to > > >>> the hotel around 8-8.30. > > >>> > > >>> ...Mark > > >>> > > >>> > > >>> On 9/10/07 12:52 PM, "Marshall Eubanks" > > >> wrote: > > >>> > > >>>> > > >>>> On Sep 10, 2007, at 1:22 PM, Marshall Eubanks wrote: > > >>>> > > >>>>> OK, I have called the > > >>>>> > > >>>>> Stafford House Bed & Breakfast > > >>>>> 3746 Chain Bridge Road > > >>>>> Fairfax, VA 22030 > > >>>> > > >>>> They have only 1 room available - a Suite with a King size bed. > > >>>> > > >>>> $ 159 for 1 person > > >>>> $ 179 for 2 (but you have to share the bed) > > >>>> > > >>>> Regards > > >>>> Marshall > > >>>> > > >>>>> > > >>>>> to see if they have any room - they are the only one > > >> close enough > > >>>>> to comfortably walk to GMU. I don't know if they are affordable, > > >>>>> though. > > >>>>> > > >>>>> None of the others have the slightest bit of charm - I would > > >>>>> recommend the > > >>>>> > > >>>>> Courtyard by Marriott - Fair Oaks > > >>>>> 11220 Lee Jackson Hwy. > > >>>>> Fairfax, VA 22030 > > >>>>> > > >>>>> It is easy to get to by car (just off I-66), and has bus > > >> ability too. > > >>>>> > > >>>>> Regards > > >>>>> Marshall > > >>>>> > > >>>>> P.S. If any one wants to stay at > > >>>>> Canary Cottage Bed & Breakfast > > >>>>> > > >>>>> ph: (703) 322-1811 > > >>>>> > > >>>>> 8.0 miles from Fairfax Campus > > >>>>> 7153 Main Street > > >>>>> Clifton, VA 20124 > > >>>>> > > >>>>> let me know - I live in Clifton and can give you a ride. > > >>>>> > > >>>>> > > >>>>> Begin forwarded message: > > >>>>> > > >>>>>> From: Shiloh Dorgan > > >>>>>> Date: August 30, 2007 9:51:31 AM EDT > > >>>>>> To: Marshall Eubanks > > >>>>>> Cc: fecframe-proto@ietf.org, Mark Pullen > > >> > > >>>>>> Subject: Re: FECFRAME Design Meeting in Fairfax > > >>>>>> > > >>>>>> Here are the details:: > > >>>>>> > > >>>>>> Area hotels: http://www.gmu.edu/welcome/hotel.html#FAIRFAX > > >>>>>> > > >>>>>> 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. > > >>>>>> > > >>>>>> Shiloh > > >>>>>> > > >>>>>> Marshall Eubanks 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 > > > > > _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Fri Sep 21 07:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYh6J-0004l0-FZ; Fri, 21 Sep 2007 07:55:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYh6H-0004hS-BQ for fecframe-proto@ietf.org; Fri, 21 Sep 2007 07:55:13 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYh6G-0000EV-L9 for fecframe-proto@ietf.org; Fri, 21 Sep 2007 07:55:13 -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 8456513 for fecframe-proto@ietf.org; Fri, 21 Sep 2007 07:55:12 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: fecframe-proto@ietf.org From: Marshall Eubanks Date: Fri, 21 Sep 2007 07:55:09 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [FECFRAME-PROTO] Packet MTU and other IP header issues X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Note this text from Section 6.3 The IP and transport header fields MUST be identical to those of the original source packet. The Original transport Payload field MUST be identical to the transport payload of the original source packet. The transport payload of the FEC Source packet MUST consist of the Original Transport Payload followed by the Source FEC Payload ID field, if required. There are certain problems with this if you are thinking of a "dumb source" sending to a FEC box and then out to the world. As this is the use case I am personally interested in, and as I see this as the likely major use for FECFRAMEs, we need to support it. Note that the above text states clearly that _FEC protected sources keep their original source IP addresses_. If the FEC protection is not done in the same box, it is a _middleware_ box. There was some discussion earlier this week that implied otherwise. Now, some things are clearly missing here : - I think that the RTT MUST be decremented by 1 if the FEC is applied by another box. (You don't want loops of the form Source -> FEC -> Source -> FEC -> infinity.) - The _Length_ field of the IP header MUST be changed if the FEC Payload ID is used. - The _Length_ field of the UDP header MUST be changed if the FEC Payload ID is used. - The _Check Sum_ field of the UDP header MUST be changed if the FEC Payload ID is used. (Note that DCCP allows for check sums over part of the data of the packet, including all or none. Do we want to require DCCP in FECFRAME to extend the check sum to cover the FEC Payload ID ? Note the implication. I may say, in video encoding foo, the first 100 bytes are critical, so I will apply the checksum to them, but the next 1300 bytes are not so much, so I will tolerate bit errors, and so the check sum only applies to the first 100 bytes. Then, if we apply FEC, that means that either we have to tolerate bit errors in the FEC Payload ID, which seems very dicey, or we have to ignore their scheming. In fact, shouldn't this be done in any case ? Won't even single bit errors in payload potentially cause catastrophic errors in recovery of lost packets if the errored packet is used in their recovery ? So, - The _Check Sum_ field of the DCCP header MUST be changed if the FEC Payload ID is used, and the check sum MUST be extended to cover the entire length of the DCCP data payload, including the FEC Payload ID, if any. Now, for the MTU issue. This is something that rears its ugly head whenever you start adding headers or trailers to packets is the MTU issue. Many packets of media flows are sent at the MTU limit, so adding even a few bytes can cause the packet to be too big, resulting in fragmentation and dropped packets. Many networks will drop all fragmented packets, due to the overhead they cause and possible security worries, so just ignoring this is bad. The FEC Payload ID, if used, will definitely cause this problem. I don't see any text about this, and there needs to be. This is a mess, because the packet may have an internal sequence number, so you can't just have the FEC scheme divide them. Solutions are - a statement on source configuration should be added : Sources of data intended for the application of FEC SHOULD be configured to allow for the insertion of the maximum size FEC Payload ID if the MTU of the distribution network is known, and MUST be configured to not send packets large enough to violate the maximum size of an IP packet once the FEC Payload ID is added. - We could make the FEC scheme know or guess the MTU and do something if it will violate it, like replacing data packets for repair packets if the MTU will be violated (this seems very dicey to me for a bunch of reasons). Any ideas ? I think I should send this to the WG list. Regards Marshall P.S. Note that in the IETF web site, expired WG drafts can be found at sites like http://tools.ietf.org/wg/fecframe/ for each WG. _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Fri Sep 21 08:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYi5P-0007em-VP; Fri, 21 Sep 2007 08:58:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhXz-0000Cp-VQ for fecframe-proto@ietf.org; Fri, 21 Sep 2007 08:23:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYhXz-0001Xw-B4 for fecframe-proto@ietf.org; Fri, 21 Sep 2007 08:23:51 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Sep 2007 08:23:51 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8LCNprK018162 for ; Fri, 21 Sep 2007 08:23:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8LCNmV4013746 for ; Fri, 21 Sep 2007 12:23:50 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 08:23:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2007 08:23:26 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6041E81D0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing up Thread-Index: Acf8SjYUmY0F71rbSlyRFFhEDxCY9A== From: "Rajiv Asati \(rajiva\)" To: X-OriginalArrivalTime: 21 Sep 2007 12:23:48.0853 (UTC) FILETIME=[4332CA50:01C7FC4A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5; t=1190377431; x=1191241431; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20\(rajiva\)=22=20 |Subject:=20Signing=20up |Sender:=20 |To:=20; bh=NQrejmmquZ0AtcchsGxUKGfpU+W9REop/Xqgr2O6TCA=; b=rBd6RXsp2J6rqXSMrQmV9X6th3IBjrX8OAsdocZQ4fsKfXHBOw3YshVRSWqmeoZ9bZA35o06 czLNEvJUFENvnNrm+candBbiGUtylIZ7xcpnAInb4tFslsj/vsuw4Vtb; Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 X-Mailman-Approved-At: Fri, 21 Sep 2007 08:58:23 -0400 Subject: [FECFRAME-PROTO] Signing up X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org =20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Sat Sep 22 20:48:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFdb-0007f4-3b; Sat, 22 Sep 2007 20:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFda-0007d2-0Q for fecframe-proto@ietf.org; Sat, 22 Sep 2007 20:47:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZFdT-00047W-GQ for fecframe-proto@ietf.org; Sat, 22 Sep 2007 20:47:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,287,1186383600"; d="scan'208";a="223317976" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Sep 2007 17:47:42 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8N0lflY010980; Sat, 22 Sep 2007 17:47:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8N0lfDr027439; Sun, 23 Sep 2007 00:47:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Sep 2007 17:47:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] SDP params for FEC Date: Sat, 22 Sep 2007 17:47:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] SDP params for FEC thread-index: Acftzox5XqhdEoF6Sh2UTLCHdyT+PAGJ+5xwAAInACcCLgCgsA== References: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> From: "Ali Begen \(abegen\)" To: "Mark Watson" , X-OriginalArrivalTime: 23 Sep 2007 00:47:41.0523 (UTC) FILETIME=[58C18230:01C7FD7B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13169; t=1190508461; x=1191372461; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20SDP=20params=20for=20FEC |Sender:=20; bh=Z0GIzIXhiUcqzx5he7UHAwavBMN5CUFGSqP0cmVKJVg=; b=be0ttUzQAtzpvtT8pkbvXyzfI+8W7mhiuueQIxDv9a+cCngjwAWmk/d1OvsefM8c71dKsGxq UWfnMj6JW9SaavuTMEDJGrwnXkhkPfZfPe3iuB1/7aqNTk+uvAkA88aX85Fy/54G0q1StvIQI6 a90HbEE2NAlykZhrsNqvc5G2Q=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org 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 ...=20 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 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Monday, September 10, 2007 4:06 PM > To: Ali Begen (abegen); fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] SDP params for FEC >=20 > Ali, >=20 > I agree. This is an important topic for next week. >=20 > The current fecframe draft envisages an approach similar to=20 > that taken by the FEC Building Block in RMT. In this approach=20 > we would define 'containers' > for FEC-scheme-specific information, with the intention that=20 > each FEC Scheme will define exactly the information it needs=20 > and how it should be coded into the container. >=20 > Content delivery protocols can then define mechanisms for=20 > carrying these 'containers' in a way which is independent of=20 > the FEC Scheme used. >=20 > So, the first task is for us to identify which information is=20 > 'FEC Scheme independent', for which we must define specific=20 > protocol elements. This includes at least the identity of the=20 > FEC Scheme. Then we can define a container for the=20 > FEC-Scheme-specific information. In RMT, both kinds of=20 > information are referred to as FEC Object Transmission Information. >=20 > FYI, in DVB they have their own XML-based 'Service Discovery=20 > and Selection' > scheme which is used to advertise services and communicate=20 > the information needed to access the service (e.g. Multicast=20 > address). The FEC information is carried here too. DVB also=20 > defines RTSP headers to negotiate this information. >=20 > ...Mark >=20 >=20 > On 9/10/07 3:18 PM, "Ali Begen (abegen)" wrote: >=20 > > Hi everyone, > >=20 > > One topic that I believe we need to discuss is the definition of=20 > > FEC-related parameters within SDP. That is, we need to=20 > identify what=20 > > kind of FEC parameters need to be conveyed through SDP between the > > receiver(s) and sender(s) so that the senders generate the=20 > right FEC=20 > > and the receivers know what they receive. Possible=20 > parameters are the=20 > > session identifiers, protection period, block size, FEC=20 > coding scheme,=20 > > FEC type, annex type (sending arrangements), etc. > >=20 > > Some parameters are algorithm-specific (e.g., L and D=20 > values for CoP3=20 > > and the seed information for Raptor). We may need these as well,=20 > > however, we should have the right amount of abstraction. > >=20 > > As far as I know, there is not much about this in the current IETF=20 > > documents. DVB is pushing for the hybrid FEC (CoP3 +=20 > Raptor), however,=20 > > I am not sure what is proposed to negogiate the algorithm-specific=20 > > parameters between the receiver and sender. RFC 4756 is not=20 > much help=20 > > from this perspective, either. > >=20 > > I am hoping we can make a progress in this front and will=20 > have a draft=20 > > for the December meeting. > >=20 > > BTW, this work may require a joint collaboration between=20 > FECframe and=20 > > MMUSIC as well as AVT WGs. > >=20 > > Ali > >=20 > >=20 > >=20 > > =20 > >=20 > >> -----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;=20 > >> fecframe-proto@ietf.org; Shiloh Dorgan > >> Subject: Re: [FECFRAME-PROTO] Re: FECFRAME Design Meeting=20 > in Fairfax > >>=20 > >> Yes, a bit.. Sorry I haven't sent something out before but=20 > I've been=20 > >> on the road the past week and still have more road ahead. > >>=20 > >> What we need first is for someone to volunteer to outline=20 > the current=20 > >> relevant work from the other groups, ie RMT > >>=20 > >> Mark is the primary keeper of our requirements draft so we need=20 > >> confirmation that he will be able to make the interim meeting. > >>=20 > >> Then with the requirements and an understanding of the current=20 > >> relevant work we can begin to address what extensions are=20 > necessary=20 > >> to meet our goals of FECFrame. > >>=20 > >> So who is willing and able to provide the outline of=20 > current relevant=20 > >> work? > >>=20 > >> Thanks, > >> Greg > >>=20 > >> On 9/2/07, Michael Bany wrote: > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Do we have any kind of simple agenda? > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] > >>> Sent: Friday, August 31, 2007 6:39 PM > >>> To: Michael Bany; Ulas Kozat; Marshall Eubanks > >>>=20 > >>> Cc: Shiloh Dorgan; Mark Pullen; fecframe-proto@ietf.org > >>> Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting > >> in Fairfax > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> I will be driving from RTP on Saturday. So, I can join a=20 > dinner on=20 > >>> Sunday if anybody interested. I'll leave at 8pm on 18th=20 > out of DCA. > >>> And, we can start at 9am on both days. > >>>=20 > >>>=20 > >>>=20 > >>> You all have a nice long weekend. > >>>=20 > >>>=20 > >>>=20 > >>> - Ali > >>>=20 > >>>=20 > >>>=20 > >>> ________________________________ > >>>=20 > >>>=20 > >>> 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 > >>>=20 > >>> I will be arriving late night Sunday and depart out of > >> Reagan National > >>> at 5:30 pm on the 18th of September. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> 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 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Greetings-- > >>>=20 > >>> I will be arriving late night Sunday and return back on 18th (my=20 > >>> reserved flight leaves at 4:45pm from Reagan National). > >>>=20 > >>> Do we have a tentative schedule/agenda? If the meetings > >> will continue > >>> until late evening on 18th, I might change my schedule. > >>>=20 > >>> Ulas > >>>=20 > >>>=20 > >>> On 8/30/07, Marshall Eubanks wrote: > >>>=20 > >>> OK, having waited for the dust to settle, and having polled the=20 > >>> members who wanted the other dates, the Design team > >> meeting will be > >>> at George Mason University 17-18 September. Our thanks=20 > to GMU for=20 > >>> offering the space. > >>>=20 > >>> Mark, Shiloh, can you recommend a nearby hotel ? > >>>=20 > >>> Also, we will need directions to the exact site of the meeting. > >>>=20 > >>> Travel arrangements : > >>>=20 > >>> Either Dulles (IAD) or National (DCA) airports have easy > >> access to > >>> GMU in Fairfax, Virginia. > >>>=20 > >>> National even has subway (Metro) access - > >>>=20 > >>> http://www.wmata.com/metrorail/systemmap.cfm > >>>=20 > >>> Blue line to the Orange line, Orange line to Vienna, a > >> short cab ride > >>> or CUE bus ride to GMU. > >>>=20 > >>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp > >>>=20 > >>> I would allow at least an hour for this. A cab ride from > >> National or > >>> Dulles will cost order $ 30, maybe more from Dulles. > >>>=20 > >>> 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. > >>>=20 > >>> http://coyote.gmu.edu/map/fairfax.html > >>>=20 > >>> 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=20 > >>> Washington itself. I would not recommend it unless the=20 > flights are=20 > >>> really cheap. > >>>=20 > >>> 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. > >>>=20 > >>> If people come in early enough Sunday night we should=20 > have dinner. > >>>=20 > >>> Regards > >>> Marshall > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: > >>>=20 > >>>> 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. > >>>>=20 > >>>> Shiloh > >>>>=20 > >>>> Mark Pullen wrote: > >>>>> Marshall, > >>>>>=20 > >>>>> 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=20 > hotels >>=20 > >>> (see www.gmu.edu for info). > >>>>>=20 > >>>>> Assuming the above is OK, I'm asking Shiloh to reserve > >> a room >> > >>> for you (Shiloh, start with 320 ST2 if available). > >>>>>=20 > >>>>> Mark > >>>>>=20 > >>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: > >>>>>=20 > >>>>>> Dear Mark; > >>>>>>=20 > >>>>>> I am trying to find a place for a design team meeting for the=20 > >>>>>> Fecframe IETF working group. > >>>>>>=20 > >>>>>> Fecframe is a new working group with a charter to >>> >>> > >>> ...develop specifications for using >>> forward error correction > >>> (FEC) codes with applications in the >>> Internet >>>=20 > to provide=20 > >>> 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=20 > multicast and >>>=20 > >>> unicast. > >>>>>>=20 > >>>>>> This has the potential to become an essential piece of > >> technology > >>>>>> underpinning IPTV. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> At present, I think that everyone is available for the entire=20 > >>>>>> week, and so room availability could determine >>> > >> which two days > >>> we meet. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> Regards > >>>>>> Marshall > >>>>>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>>=20 > >>>=20 > >>=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Mon Sep 24 10:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZp3r-0000f2-J2; Mon, 24 Sep 2007 10:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZp3p-0000eP-99 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 10:37:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZp3o-0000z5-37 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 10:37:21 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186383600"; d="scan'208";a="224011699" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 07:37:19 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8OEbJUZ018873 for ; Mon, 24 Sep 2007 07:37:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8OEb8Nl016659 for ; Mon, 24 Sep 2007 14:37:19 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 07:35:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Sep 2007 07:35:57 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54059B6142@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Opacity of the scheme-specific information thread-index: Acf+uDg5U9WY4ccbQM6s80VuX7LiuA== From: "Ali Begen \(abegen\)" To: X-OriginalArrivalTime: 24 Sep 2007 14:36:00.0095 (UTC) FILETIME=[39D386F0:01C7FEB8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=731; t=1190644639; x=1191508639; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20Opacity=20of=20the=20scheme-specific=20information |Sender:=20; bh=OfaA8Z2Wcaok6WsCeDpJnAZIoQUrD82hC+wQxBS4jAU=; b=G7LfNSiSpSikFBYtxf34zVqyR6US2zlXppqoSCe24hLgNJe6VUGG8ugKud5P1kBpxDoQiOuj 7avQPJloSrjmt4yE3nUYCKE0FVAZnkto0rDoGZJRZk9Sbmt/sslPbHnA; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [FECFRAME-PROTO] Opacity of the scheme-specific information X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Hi all, I am trying to identify the pros and cons of using opaque information for signaling the fec-scheme-specific info. I am aware of that RMT adopted the same approach for object transmission information and if a receiver is not compatible with a particular FEC scheme, then it does not have to parse that information.=20 Yet, I believe it is still important to make a strong case why we put that information in an opaque form rather than in a human-readable form? I checked the RFC 5052, however, could not find much detail on this. One of my concerns is that can the opacity lead to some sort of abusing?=20 Any one with a prior experience on using opaque stuff in a protocol header? Comments? -acbegen _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Mon Sep 24 11:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZq46-0004BZ-Ha; Mon, 24 Sep 2007 11:41:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZq44-0004Aw-JD for fecframe-proto@ietf.org; Mon, 24 Sep 2007 11:41:40 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZq44-0004nX-2S for fecframe-proto@ietf.org; Mon, 24 Sep 2007 11:41:40 -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 8465344; Mon, 24 Sep 2007 11:41:37 -0400 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54059B6142@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D54059B6142@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Mon, 24 Sep 2007 11:41:32 -0400 To: "Ali Begen \(abegen\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Modern Codecs tend to use a lot of opaque information, which bugs me, but we are not going to change that. Most streaming codecs make the SDP file from the presented encoded data to stream. Encoded information might be all sorts of things, aspect ratios, GOP structure, audio bit rates, stereo vs mono, etc. If the streamer gets something wrong, it is very hard to fix it in the SDP file, even if you know what it should be, because it is opaque. This has caused me considerable pain in the past. I am sure that it more efficient to base 64 encode a 500 character string rather than send it in Ascii, but this seems a strange efficiency argument when you are talking about a SDP file (sent once) for a multiple megabit per second video stream. One argument that I haven't heard but might be there is that with the opaque blob you don't have to document what you are doing. It may just be a convenient rug to sweep things under. Regards Marshall On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: > Hi all, > > I am trying to identify the pros and cons of using opaque information > for signaling the fec-scheme-specific info. I am aware of that RMT > adopted the same approach for object transmission information and if a > receiver is not compatible with a particular FEC scheme, then it does > not have to parse that information. > > Yet, I believe it is still important to make a strong case why we put > that information in an opaque form rather than in a human-readable > form? > > I checked the RFC 5052, however, could not find much detail on > this. One > of my concerns is that can the opacity lead to some sort of abusing? > > Any one with a prior experience on using opaque stuff in a protocol > header? Comments? > > -acbegen > > _______________________________________________ > 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 11:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqGy-0007hZ-HG; Mon, 24 Sep 2007 11:55:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqGx-0007hU-Hd for fecframe-proto@ietf.org; Mon, 24 Sep 2007 11:54:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZqGw-0005Em-S8 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 11:54:59 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186383600"; d="scan'208";a="527407469" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2007 08:54:58 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8OFswws029934; Mon, 24 Sep 2007 08:54:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8OFsuip024202; Mon, 24 Sep 2007 15:54:58 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 08:54:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Mon, 24 Sep 2007 08:55:22 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54059B61C7@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information thread-index: Acf+wavpgjFWvGsiTiqXP6KxZ6fuxQAALTyA References: <04CAD96D4C5A3D48B1919248A8FE0D54059B6142@xmb-sjc-215.amer.cisco.com> From: "Ali Begen \(abegen\)" To: "Marshall Eubanks" X-OriginalArrivalTime: 24 Sep 2007 15:54:55.0698 (UTC) FILETIME=[40773320:01C7FEC3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2802; t=1190649298; x=1191513298; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Opacity=20of=20the=20scheme-specif ic=20information |Sender:=20; bh=GM0sekYITvt/n1vG2Ib275nDGM2KNa51NUxWjKbKYf0=; b=UvdDHyZAHAPghwkVloItvjExVGRN4DRsTkNuttppsmNIHIF/eGipte2n7SoXqFbCJnJ74iqR jh90zBGutWizJ67159IAKis7bepttWlpFh4JovIydf8k8p82lVCyMNeA; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Hi Marshall, See inline.=20 > Modern Codecs tend to use a lot of opaque information, which=20 > bugs me, but we are not going to change that. >=20 > Most streaming codecs make the SDP file from the presented=20 > encoded data to stream. Encoded information might be all=20 > sorts of things, aspect ratios, GOP structure, audio bit=20 > rates, stereo vs mono, etc. =20 > If the streamer gets something wrong, it is very hard to fix=20 > it in the SDP file, even if you know what it should be,=20 > because it is opaque. This has caused me considerable pain in=20 > the past. I agree, this is a concern. Actually, with the deployment of middle boxes that do some processing on the video streams flowing through them, this is indeed a problem. If the info is in Ascii, it can be repaired somwhere along the path. =20 > I am sure that it more efficient to base 64 encode a 500=20 > character string rather than send it in Ascii, but this seems=20 > a strange efficiency argument when you are talking about a=20 > SDP file (sent once) for a multiple megabit per second video stream. Yes, the coding efficiency for opaque SDP should not be the reason we are doing this. > One argument that I haven't heard but might be there is that=20 > with the opaque blob you don't have to document what you are=20 > doing. It may just be a convenient rug to sweep things under. This is what I meant with "abusing," and is our primary concern. I have not been in IETF to observe this problem and you are saying that you have not heard so far, but that does not mean that no one is doing it.=20 Any more comments? -acbegen > Regards > Marshall >=20 >=20 > On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >=20 > > Hi all, > > > > I am trying to identify the pros and cons of using opaque=20 > information=20 > > for signaling the fec-scheme-specific info. I am aware of that RMT=20 > > adopted the same approach for object transmission=20 > information and if a=20 > > receiver is not compatible with a particular FEC scheme,=20 > then it does=20 > > not have to parse that information. > > > > Yet, I believe it is still important to make a strong case=20 > why we put=20 > > that information in an opaque form rather than in a human-readable=20 > > form? > > > > I checked the RFC 5052, however, could not find much detail=20 > on this.=20 > > One of my concerns is that can the opacity lead to some sort of=20 > > abusing? > > > > Any one with a prior experience on using opaque stuff in a protocol=20 > > header? Comments? > > > > -acbegen > > > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Mon Sep 24 13:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrgl-000184-W5; Mon, 24 Sep 2007 13:25:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrgk-00017t-NP for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:25:42 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrgj-0000Yb-RB for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:25:42 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Sep 2007 17:26:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 24 Sep 2007 09:46:03 -0700 Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information From: Mark Watson To: "Ali Begen (abegen)" , Marshall Eubanks Message-ID: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf+wavpgjFWvGsiTiqXP6KxZ6fuxQAALTyAAAIA92o= In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54059B61C7@xmb-sjc-215.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org All, "Opaque" was intended to mean that the information carried is not _logically_ visible to the carrying protocol. That is, the carrying protocol does not place requirements on what can or should be carried, or make assumptions about what is there, and it delivers the information intact to the responsible component at the receiving end. "Opaque" was not intended to mean that the information is deliberately obfuscated. Also, what we are defining here is specification responsibilities, not implementation architecture: it is the responsibility of the FEC Scheme specification to define the contents of the Scheme-specific information and the responsibility of the CDP specification to specify how it is carried in a protocol. The two must be decoupled so that CDPs are not FEC-scheme-specific and vice versa. This says nothing about what implementations are allowed to do with information they find in packets: you can implement FEC-scheme-specific functionality wherever you like. The reason for using base64 is that the information is defined as a sequence of octets and you cannot carry raw octets in SDP. We could, alternatively, require that the information is ASCII and then it can be carried directly (with certain restrictions). When I said above that the protocol could not place requirements on what can be carried, this means a *particular* protocol - the FEC Framework itself can place whatever requirements we like. A reason for allowing arbitrary octets is that it allows FEC Schemes to define efficient (binary) encodings, which can then be used with other CDPs that are themselves binary coded. So, what it comes down to is that if we ask FEC Schemes to define a text-based encoding (which has the advantages implied by the mails below), then we restrict the set of possible CDPs supported by the framework to those within which text-based encoding is acceptable. I would prefer that we not make this restriction. It is, after all, no harder to write code which unpacks a base-64 encoded BLOB than to parse a sequence of text "name=value;" pairs. Regards, Mark On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: > Hi Marshall, > > See inline. > >> Modern Codecs tend to use a lot of opaque information, which >> bugs me, but we are not going to change that. >> >> Most streaming codecs make the SDP file from the presented >> encoded data to stream. Encoded information might be all >> sorts of things, aspect ratios, GOP structure, audio bit >> rates, stereo vs mono, etc. >> If the streamer gets something wrong, it is very hard to fix >> it in the SDP file, even if you know what it should be, >> because it is opaque. This has caused me considerable pain in >> the past. > > I agree, this is a concern. Actually, with the deployment of middle > boxes that do some processing on the video streams flowing through them, > this is indeed a problem. If the info is in Ascii, it can be repaired > somwhere along the path. > >> I am sure that it more efficient to base 64 encode a 500 >> character string rather than send it in Ascii, but this seems >> a strange efficiency argument when you are talking about a >> SDP file (sent once) for a multiple megabit per second video stream. > > Yes, the coding efficiency for opaque SDP should not be the reason we > are doing this. > >> One argument that I haven't heard but might be there is that >> with the opaque blob you don't have to document what you are >> doing. It may just be a convenient rug to sweep things under. > > This is what I meant with "abusing," and is our primary concern. I have > not been in IETF to observe this problem and you are saying that you > have not heard so far, but that does not mean that no one is doing it. > > Any more comments? > > -acbegen > > >> Regards >> Marshall >> >> >> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >> >>> Hi all, >>> >>> I am trying to identify the pros and cons of using opaque >> information >>> for signaling the fec-scheme-specific info. I am aware of that RMT >>> adopted the same approach for object transmission >> information and if a >>> receiver is not compatible with a particular FEC scheme, >> then it does >>> not have to parse that information. >>> >>> Yet, I believe it is still important to make a strong case >> why we put >>> that information in an opaque form rather than in a human-readable >>> form? >>> >>> I checked the RFC 5052, however, could not find much detail >> on this. >>> One of my concerns is that can the opacity lead to some sort of >>> abusing? >>> >>> Any one with a prior experience on using opaque stuff in a protocol >>> header? Comments? >>> >>> -acbegen >>> >>> _______________________________________________ >>> 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 13:31:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrmm-0001zy-RD; Mon, 24 Sep 2007 13:31:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrml-0001os-0d for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:31:55 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrmk-0000nR-6t for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:31:54 -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 8465694; Mon, 24 Sep 2007 13:31:53 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E39F7C4-B1BD-4560-B721-3080E40AB0CD@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Mon, 24 Sep 2007 13:31:48 -0400 To: Mark Watson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Are we going to require instantiations to publish pseudo-code to describe how to read the opaque parts ? (AVT does not.) Regards Marshall On Sep 24, 2007, at 12:46 PM, Mark Watson wrote: > All, > > "Opaque" was intended to mean that the information carried is not > _logically_ visible to the carrying protocol. That is, the carrying > protocol > does not place requirements on what can or should be carried, or make > assumptions about what is there, and it delivers the information > intact to > the responsible component at the receiving end. > > "Opaque" was not intended to mean that the information is deliberately > obfuscated. > > Also, what we are defining here is specification responsibilities, not > implementation architecture: it is the responsibility of the FEC > Scheme > specification to define the contents of the Scheme-specific > information and > the responsibility of the CDP specification to specify how it is > carried in > a protocol. The two must be decoupled so that CDPs are not > FEC-scheme-specific and vice versa. This says nothing about what > implementations are allowed to do with information they find in > packets: you > can implement FEC-scheme-specific functionality wherever you like. > > The reason for using base64 is that the information is defined as a > sequence > of octets and you cannot carry raw octets in SDP. We could, > alternatively, > require that the information is ASCII and then it can be carried > directly > (with certain restrictions). When I said above that the protocol > could not > place requirements on what can be carried, this means a *particular* > protocol - the FEC Framework itself can place whatever requirements > we like. > > A reason for allowing arbitrary octets is that it allows FEC > Schemes to > define efficient (binary) encodings, which can then be used with > other CDPs > that are themselves binary coded. > > So, what it comes down to is that if we ask FEC Schemes to define a > text-based encoding (which has the advantages implied by the mails > below), > then we restrict the set of possible CDPs supported by the > framework to > those within which text-based encoding is acceptable. > > I would prefer that we not make this restriction. It is, after all, no > harder to write code which unpacks a base-64 encoded BLOB than to > parse a > sequence of text "name=value;" pairs. > > Regards, > > Mark > > > On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: > >> Hi Marshall, >> >> See inline. >> >>> Modern Codecs tend to use a lot of opaque information, which >>> bugs me, but we are not going to change that. >>> >>> Most streaming codecs make the SDP file from the presented >>> encoded data to stream. Encoded information might be all >>> sorts of things, aspect ratios, GOP structure, audio bit >>> rates, stereo vs mono, etc. >>> If the streamer gets something wrong, it is very hard to fix >>> it in the SDP file, even if you know what it should be, >>> because it is opaque. This has caused me considerable pain in >>> the past. >> >> I agree, this is a concern. Actually, with the deployment of middle >> boxes that do some processing on the video streams flowing through >> them, >> this is indeed a problem. If the info is in Ascii, it can be repaired >> somwhere along the path. >> >>> I am sure that it more efficient to base 64 encode a 500 >>> character string rather than send it in Ascii, but this seems >>> a strange efficiency argument when you are talking about a >>> SDP file (sent once) for a multiple megabit per second video stream. >> >> Yes, the coding efficiency for opaque SDP should not be the reason we >> are doing this. >> >>> One argument that I haven't heard but might be there is that >>> with the opaque blob you don't have to document what you are >>> doing. It may just be a convenient rug to sweep things under. >> >> This is what I meant with "abusing," and is our primary concern. I >> have >> not been in IETF to observe this problem and you are saying that you >> have not heard so far, but that does not mean that no one is doing >> it. >> >> Any more comments? >> >> -acbegen >> >> >>> Regards >>> Marshall >>> >>> >>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>> >>>> Hi all, >>>> >>>> I am trying to identify the pros and cons of using opaque >>> information >>>> for signaling the fec-scheme-specific info. I am aware of that RMT >>>> adopted the same approach for object transmission >>> information and if a >>>> receiver is not compatible with a particular FEC scheme, >>> then it does >>>> not have to parse that information. >>>> >>>> Yet, I believe it is still important to make a strong case >>> why we put >>>> that information in an opaque form rather than in a human-readable >>>> form? >>>> >>>> I checked the RFC 5052, however, could not find much detail >>> on this. >>>> One of my concerns is that can the opacity lead to some sort of >>>> abusing? >>>> >>>> Any one with a prior experience on using opaque stuff in a protocol >>>> header? Comments? >>>> >>>> -acbegen >>>> >>>> _______________________________________________ >>>> 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 13:41:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrwD-0004Ku-Ij; Mon, 24 Sep 2007 13:41:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrwC-0004JZ-BS for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:41:40 -0400 Received: from www.amesweb.com ([216.218.233.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrwB-00015S-Ag for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:41:40 -0400 Received: from exchange.amesweb.com ([12.215.108.10]) by www.amesweb.com with esmtp (Exim 4.10) id 1IZrwA-00016H-00 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 12:41:38 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Opacity of the scheme-specific information X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 24 Sep 2007 12:41:31 -0500 Message-ID: In-Reply-To: <6E39F7C4-B1BD-4560-B721-3080E40AB0CD@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf+0M526vBZJR0DRD2zZSMJcXQmrwAATMwQ References: <6E39F7C4-B1BD-4560-B721-3080E40AB0CD@multicasttech.com> From: "Michael Bany" To: "Marshall Eubanks" , "Mark Watson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I wonder if this would cause problems with proprietary schemes. Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 Sent: Monday, September 24, 2007 12:32 PM To: Mark Watson Cc: fecframe-proto@ietf.org Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information Are we going to require instantiations to publish pseudo-code to =20 describe how to read the opaque parts ? (AVT does not.) Regards Marshall On Sep 24, 2007, at 12:46 PM, Mark Watson wrote: > All, > > "Opaque" was intended to mean that the information carried is not > _logically_ visible to the carrying protocol. That is, the carrying =20 > protocol > does not place requirements on what can or should be carried, or make > assumptions about what is there, and it delivers the information =20 > intact to > the responsible component at the receiving end. > > "Opaque" was not intended to mean that the information is deliberately > obfuscated. > > Also, what we are defining here is specification responsibilities, not > implementation architecture: it is the responsibility of the FEC =20 > Scheme > specification to define the contents of the Scheme-specific =20 > information and > the responsibility of the CDP specification to specify how it is =20 > carried in > a protocol. The two must be decoupled so that CDPs are not > FEC-scheme-specific and vice versa. This says nothing about what > implementations are allowed to do with information they find in =20 > packets: you > can implement FEC-scheme-specific functionality wherever you like. > > The reason for using base64 is that the information is defined as a =20 > sequence > of octets and you cannot carry raw octets in SDP. We could, =20 > alternatively, > require that the information is ASCII and then it can be carried =20 > directly > (with certain restrictions). When I said above that the protocol =20 > could not > place requirements on what can be carried, this means a *particular* > protocol - the FEC Framework itself can place whatever requirements =20 > we like. > > A reason for allowing arbitrary octets is that it allows FEC =20 > Schemes to > define efficient (binary) encodings, which can then be used with =20 > other CDPs > that are themselves binary coded. > > So, what it comes down to is that if we ask FEC Schemes to define a > text-based encoding (which has the advantages implied by the mails =20 > below), > then we restrict the set of possible CDPs supported by the =20 > framework to > those within which text-based encoding is acceptable. > > I would prefer that we not make this restriction. It is, after all, no > harder to write code which unpacks a base-64 encoded BLOB than to =20 > parse a > sequence of text "name=3Dvalue;" pairs. > > Regards, > > Mark > > > On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: > >> Hi Marshall, >> >> See inline. >> >>> Modern Codecs tend to use a lot of opaque information, which >>> bugs me, but we are not going to change that. >>> >>> Most streaming codecs make the SDP file from the presented >>> encoded data to stream. Encoded information might be all >>> sorts of things, aspect ratios, GOP structure, audio bit >>> rates, stereo vs mono, etc. >>> If the streamer gets something wrong, it is very hard to fix >>> it in the SDP file, even if you know what it should be, >>> because it is opaque. This has caused me considerable pain in >>> the past. >> >> I agree, this is a concern. Actually, with the deployment of middle >> boxes that do some processing on the video streams flowing through =20 >> them, >> this is indeed a problem. If the info is in Ascii, it can be repaired >> somwhere along the path. >> >>> I am sure that it more efficient to base 64 encode a 500 >>> character string rather than send it in Ascii, but this seems >>> a strange efficiency argument when you are talking about a >>> SDP file (sent once) for a multiple megabit per second video stream. >> >> Yes, the coding efficiency for opaque SDP should not be the reason we >> are doing this. >> >>> One argument that I haven't heard but might be there is that >>> with the opaque blob you don't have to document what you are >>> doing. It may just be a convenient rug to sweep things under. >> >> This is what I meant with "abusing," and is our primary concern. I =20 >> have >> not been in IETF to observe this problem and you are saying that you >> have not heard so far, but that does not mean that no one is doing =20 >> it. >> >> Any more comments? >> >> -acbegen >> >> >>> Regards >>> Marshall >>> >>> >>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>> >>>> Hi all, >>>> >>>> I am trying to identify the pros and cons of using opaque >>> information >>>> for signaling the fec-scheme-specific info. I am aware of that RMT >>>> adopted the same approach for object transmission >>> information and if a >>>> receiver is not compatible with a particular FEC scheme, >>> then it does >>>> not have to parse that information. >>>> >>>> Yet, I believe it is still important to make a strong case >>> why we put >>>> that information in an opaque form rather than in a human-readable >>>> form? >>>> >>>> I checked the RFC 5052, however, could not find much detail >>> on this. >>>> One of my concerns is that can the opacity lead to some sort of >>>> abusing? >>>> >>>> Any one with a prior experience on using opaque stuff in a protocol >>>> header? Comments? >>>> >>>> -acbegen >>>> >>>> _______________________________________________ >>>> 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 13:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrwG-0004Tp-LB; Mon, 24 Sep 2007 13:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrwF-0004Qa-UF for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:41:43 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZrwA-0007Rv-F1 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 13:41:43 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Sep 2007 17:42:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 24 Sep 2007 10:41:20 -0700 Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information From: Mark Watson To: Marshall Eubanks Message-ID: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf+0PlqSaAphSeCSCCw8Z4yfxeuFgAASRlG In-Reply-To: <6E39F7C4-B1BD-4560-B721-3080E40AB0CD@multicasttech.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org FEC schemes must describe the encoding format of the data in the usual, if that's what you mean. I don't think pseudo-code is necessary. ...Mark On 9/24/07 10:31 AM, "Marshall Eubanks" wrote: > Are we going to require instantiations to publish pseudo-code to > describe how to read the opaque parts ? > (AVT does not.) > > Regards > Marshall > > On Sep 24, 2007, at 12:46 PM, Mark Watson wrote: > >> All, >> >> "Opaque" was intended to mean that the information carried is not >> _logically_ visible to the carrying protocol. That is, the carrying >> protocol >> does not place requirements on what can or should be carried, or make >> assumptions about what is there, and it delivers the information >> intact to >> the responsible component at the receiving end. >> >> "Opaque" was not intended to mean that the information is deliberately >> obfuscated. >> >> Also, what we are defining here is specification responsibilities, not >> implementation architecture: it is the responsibility of the FEC >> Scheme >> specification to define the contents of the Scheme-specific >> information and >> the responsibility of the CDP specification to specify how it is >> carried in >> a protocol. The two must be decoupled so that CDPs are not >> FEC-scheme-specific and vice versa. This says nothing about what >> implementations are allowed to do with information they find in >> packets: you >> can implement FEC-scheme-specific functionality wherever you like. >> >> The reason for using base64 is that the information is defined as a >> sequence >> of octets and you cannot carry raw octets in SDP. We could, >> alternatively, >> require that the information is ASCII and then it can be carried >> directly >> (with certain restrictions). When I said above that the protocol >> could not >> place requirements on what can be carried, this means a *particular* >> protocol - the FEC Framework itself can place whatever requirements >> we like. >> >> A reason for allowing arbitrary octets is that it allows FEC >> Schemes to >> define efficient (binary) encodings, which can then be used with >> other CDPs >> that are themselves binary coded. >> >> So, what it comes down to is that if we ask FEC Schemes to define a >> text-based encoding (which has the advantages implied by the mails >> below), >> then we restrict the set of possible CDPs supported by the >> framework to >> those within which text-based encoding is acceptable. >> >> I would prefer that we not make this restriction. It is, after all, no >> harder to write code which unpacks a base-64 encoded BLOB than to >> parse a >> sequence of text "name=value;" pairs. >> >> Regards, >> >> Mark >> >> >> On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >> >>> Hi Marshall, >>> >>> See inline. >>> >>>> Modern Codecs tend to use a lot of opaque information, which >>>> bugs me, but we are not going to change that. >>>> >>>> Most streaming codecs make the SDP file from the presented >>>> encoded data to stream. Encoded information might be all >>>> sorts of things, aspect ratios, GOP structure, audio bit >>>> rates, stereo vs mono, etc. >>>> If the streamer gets something wrong, it is very hard to fix >>>> it in the SDP file, even if you know what it should be, >>>> because it is opaque. This has caused me considerable pain in >>>> the past. >>> >>> I agree, this is a concern. Actually, with the deployment of middle >>> boxes that do some processing on the video streams flowing through >>> them, >>> this is indeed a problem. If the info is in Ascii, it can be repaired >>> somwhere along the path. >>> >>>> I am sure that it more efficient to base 64 encode a 500 >>>> character string rather than send it in Ascii, but this seems >>>> a strange efficiency argument when you are talking about a >>>> SDP file (sent once) for a multiple megabit per second video stream. >>> >>> Yes, the coding efficiency for opaque SDP should not be the reason we >>> are doing this. >>> >>>> One argument that I haven't heard but might be there is that >>>> with the opaque blob you don't have to document what you are >>>> doing. It may just be a convenient rug to sweep things under. >>> >>> This is what I meant with "abusing," and is our primary concern. I >>> have >>> not been in IETF to observe this problem and you are saying that you >>> have not heard so far, but that does not mean that no one is doing >>> it. >>> >>> Any more comments? >>> >>> -acbegen >>> >>> >>>> Regards >>>> Marshall >>>> >>>> >>>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying to identify the pros and cons of using opaque >>>> information >>>>> for signaling the fec-scheme-specific info. I am aware of that RMT >>>>> adopted the same approach for object transmission >>>> information and if a >>>>> receiver is not compatible with a particular FEC scheme, >>>> then it does >>>>> not have to parse that information. >>>>> >>>>> Yet, I believe it is still important to make a strong case >>>> why we put >>>>> that information in an opaque form rather than in a human-readable >>>>> form? >>>>> >>>>> I checked the RFC 5052, however, could not find much detail >>>> on this. >>>>> One of my concerns is that can the opacity lead to some sort of >>>>> abusing? >>>>> >>>>> Any one with a prior experience on using opaque stuff in a protocol >>>>> header? Comments? >>>>> >>>>> -acbegen >>>>> >>>>> _______________________________________________ >>>>> 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 14:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsKj-0006Xw-7x; Mon, 24 Sep 2007 14:07:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsKi-0006TR-37 for fecframe-proto@ietf.org; Mon, 24 Sep 2007 14:07:00 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZsKh-0001wd-6g for fecframe-proto@ietf.org; Mon, 24 Sep 2007 14:06:59 -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 8465763; Mon, 24 Sep 2007 14:06:58 -0400 In-Reply-To: References: <6E39F7C4-B1BD-4560-B721-3080E40AB0CD@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46F824A8-FC3A-45B9-B20F-6D04D6E58AF8@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Mon, 24 Sep 2007 14:06:53 -0400 To: "Michael Bany" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org That is a real concern. I suspect we can't mandate any such thing, for non fully specified schemes. I would say that a fully specified scheme should have this information. Regards Marshall On Sep 24, 2007, at 1:41 PM, Michael Bany wrote: > I wonder if this would cause problems with proprietary schemes. > > Mike > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Monday, September 24, 2007 12:32 PM > To: Mark Watson > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific > information > > Are we going to require instantiations to publish pseudo-code to > describe how to read the opaque parts ? > (AVT does not.) > > Regards > Marshall > > On Sep 24, 2007, at 12:46 PM, Mark Watson wrote: > >> All, >> >> "Opaque" was intended to mean that the information carried is not >> _logically_ visible to the carrying protocol. That is, the carrying >> protocol >> does not place requirements on what can or should be carried, or make >> assumptions about what is there, and it delivers the information >> intact to >> the responsible component at the receiving end. >> >> "Opaque" was not intended to mean that the information is >> deliberately >> obfuscated. >> >> Also, what we are defining here is specification responsibilities, >> not >> implementation architecture: it is the responsibility of the FEC >> Scheme >> specification to define the contents of the Scheme-specific >> information and >> the responsibility of the CDP specification to specify how it is >> carried in >> a protocol. The two must be decoupled so that CDPs are not >> FEC-scheme-specific and vice versa. This says nothing about what >> implementations are allowed to do with information they find in >> packets: you >> can implement FEC-scheme-specific functionality wherever you like. >> >> The reason for using base64 is that the information is defined as a >> sequence >> of octets and you cannot carry raw octets in SDP. We could, >> alternatively, >> require that the information is ASCII and then it can be carried >> directly >> (with certain restrictions). When I said above that the protocol >> could not >> place requirements on what can be carried, this means a *particular* >> protocol - the FEC Framework itself can place whatever requirements >> we like. >> >> A reason for allowing arbitrary octets is that it allows FEC >> Schemes to >> define efficient (binary) encodings, which can then be used with >> other CDPs >> that are themselves binary coded. >> >> So, what it comes down to is that if we ask FEC Schemes to define a >> text-based encoding (which has the advantages implied by the mails >> below), >> then we restrict the set of possible CDPs supported by the >> framework to >> those within which text-based encoding is acceptable. >> >> I would prefer that we not make this restriction. It is, after >> all, no >> harder to write code which unpacks a base-64 encoded BLOB than to >> parse a >> sequence of text "name=value;" pairs. >> >> Regards, >> >> Mark >> >> >> On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >> >>> Hi Marshall, >>> >>> See inline. >>> >>>> Modern Codecs tend to use a lot of opaque information, which >>>> bugs me, but we are not going to change that. >>>> >>>> Most streaming codecs make the SDP file from the presented >>>> encoded data to stream. Encoded information might be all >>>> sorts of things, aspect ratios, GOP structure, audio bit >>>> rates, stereo vs mono, etc. >>>> If the streamer gets something wrong, it is very hard to fix >>>> it in the SDP file, even if you know what it should be, >>>> because it is opaque. This has caused me considerable pain in >>>> the past. >>> >>> I agree, this is a concern. Actually, with the deployment of middle >>> boxes that do some processing on the video streams flowing through >>> them, >>> this is indeed a problem. If the info is in Ascii, it can be >>> repaired >>> somwhere along the path. >>> >>>> I am sure that it more efficient to base 64 encode a 500 >>>> character string rather than send it in Ascii, but this seems >>>> a strange efficiency argument when you are talking about a >>>> SDP file (sent once) for a multiple megabit per second video >>>> stream. >>> >>> Yes, the coding efficiency for opaque SDP should not be the >>> reason we >>> are doing this. >>> >>>> One argument that I haven't heard but might be there is that >>>> with the opaque blob you don't have to document what you are >>>> doing. It may just be a convenient rug to sweep things under. >>> >>> This is what I meant with "abusing," and is our primary concern. I >>> have >>> not been in IETF to observe this problem and you are saying that you >>> have not heard so far, but that does not mean that no one is doing >>> it. >>> >>> Any more comments? >>> >>> -acbegen >>> >>> >>>> Regards >>>> Marshall >>>> >>>> >>>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying to identify the pros and cons of using opaque >>>> information >>>>> for signaling the fec-scheme-specific info. I am aware of that RMT >>>>> adopted the same approach for object transmission >>>> information and if a >>>>> receiver is not compatible with a particular FEC scheme, >>>> then it does >>>>> not have to parse that information. >>>>> >>>>> Yet, I believe it is still important to make a strong case >>>> why we put >>>>> that information in an opaque form rather than in a human-readable >>>>> form? >>>>> >>>>> I checked the RFC 5052, however, could not find much detail >>>> on this. >>>>> One of my concerns is that can the opacity lead to some sort of >>>>> abusing? >>>>> >>>>> Any one with a prior experience on using opaque stuff in a >>>>> protocol >>>>> header? Comments? >>>>> >>>>> -acbegen >>>>> >>>>> _______________________________________________ >>>>> 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 From fecframe-proto-bounces@ietf.org Mon Sep 24 17:16:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvHt-0001IY-N6; Mon, 24 Sep 2007 17:16:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvHt-0001IS-1h for fecframe-proto@ietf.org; Mon, 24 Sep 2007 17:16:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZvHr-0008AE-TB for fecframe-proto@ietf.org; Mon, 24 Sep 2007 17:16:16 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186383600"; d="scan'208";a="401446815" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2007 14:16:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8OLGC6X026919; Mon, 24 Sep 2007 14:16:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8OLGBX1017226; Mon, 24 Sep 2007 21:16:12 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 14:16:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Mon, 24 Sep 2007 14:16:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54059B649F@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information thread-index: Acf+wavpgjFWvGsiTiqXP6KxZ6fuxQAALTyAAAIA92oACTZ6cA== References: <04CAD96D4C5A3D48B1919248A8FE0D54059B61C7@xmb-sjc-215.amer.cisco.com> From: "Ali Begen \(abegen\)" To: "Mark Watson" , "Marshall Eubanks" X-OriginalArrivalTime: 24 Sep 2007 21:16:11.0746 (UTC) FILETIME=[21E2B420:01C7FEF0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6301; t=1190668572; x=1191532572; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Opacity=20of=20the=20scheme-specif ic=20information |Sender:=20; bh=E6/KPiNw8bSgmGo8bDX2d3vtw2spx1NZa1g+zJa/HuE=; b=phpNVseXwnxMhI5t0ncOX1WPkNMdy93Q7PYyHrX6d8SxMEfWUYfz83MMwDyz05xs1bmUtHar 5ZtcotSS/biP1nt/gSmw372NPePkBHSsZVS2FCkxLZD2wTsy7GLTNOe9uDYjGTLyAWofGyli0+ pd6y8MSmkQY6hSiVaSH4gK4dA=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Hi Mark, Which ones fall out of the set of "CDPs to those within which text-based encoding is acceptable"? Are there many that do not allow text-baed encoding? Do we have an approximate number? Of course, if there are many out there, we should leave it as is. -acbegen =20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Monday, September 24, 2007 9:46 AM > To: Ali Begen (abegen); Marshall Eubanks > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific=20 > information >=20 > All, >=20 > "Opaque" was intended to mean that the information carried is=20 > not _logically_ visible to the carrying protocol. That is,=20 > the carrying protocol does not place requirements on what can=20 > or should be carried, or make assumptions about what is=20 > there, and it delivers the information intact to the=20 > responsible component at the receiving end. >=20 > "Opaque" was not intended to mean that the information is=20 > deliberately obfuscated. >=20 > Also, what we are defining here is specification=20 > responsibilities, not implementation architecture: it is the=20 > responsibility of the FEC Scheme specification to define the=20 > contents of the Scheme-specific information and the=20 > responsibility of the CDP specification to specify how it is=20 > carried in a protocol. The two must be decoupled so that CDPs=20 > are not FEC-scheme-specific and vice versa. This says nothing=20 > about what implementations are allowed to do with information=20 > they find in packets: you can implement FEC-scheme-specific=20 > functionality wherever you like. >=20 > The reason for using base64 is that the information is=20 > defined as a sequence of octets and you cannot carry raw=20 > octets in SDP. We could, alternatively, require that the=20 > information is ASCII and then it can be carried directly=20 > (with certain restrictions). When I said above that the=20 > protocol could not place requirements on what can be carried,=20 > this means a *particular* protocol - the FEC Framework itself=20 > can place whatever requirements we like. >=20 > A reason for allowing arbitrary octets is that it allows FEC=20 > Schemes to define efficient (binary) encodings, which can=20 > then be used with other CDPs that are themselves binary coded. >=20 > So, what it comes down to is that if we ask FEC Schemes to=20 > define a text-based encoding (which has the advantages=20 > implied by the mails below), then we restrict the set of=20 > possible CDPs supported by the framework to those within=20 > which text-based encoding is acceptable. >=20 > I would prefer that we not make this restriction. It is,=20 > after all, no harder to write code which unpacks a base-64=20 > encoded BLOB than to parse a sequence of text "name=3Dvalue;" pairs. >=20 > Regards, >=20 > Mark >=20 >=20 > On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >=20 > > Hi Marshall, > >=20 > > See inline.=20 > >=20 > >> Modern Codecs tend to use a lot of opaque information,=20 > which bugs me,=20 > >> but we are not going to change that. > >>=20 > >> Most streaming codecs make the SDP file from the presented encoded=20 > >> data to stream. Encoded information might be all sorts of things,=20 > >> aspect ratios, GOP structure, audio bit rates, stereo vs mono, etc. > >> If the streamer gets something wrong, it is very hard to fix it in=20 > >> the SDP file, even if you know what it should be, because it is=20 > >> opaque. This has caused me considerable pain in the past. > >=20 > > I agree, this is a concern. Actually, with the deployment of middle=20 > > boxes that do some processing on the video streams flowing through=20 > > them, this is indeed a problem. If the info is in Ascii, it can be=20 > > repaired somwhere along the path. > > =20 > >> I am sure that it more efficient to base 64 encode a 500 character=20 > >> string rather than send it in Ascii, but this seems a strange=20 > >> efficiency argument when you are talking about a SDP file=20 > (sent once)=20 > >> for a multiple megabit per second video stream. > >=20 > > Yes, the coding efficiency for opaque SDP should not be the=20 > reason we=20 > > are doing this. > >=20 > >> One argument that I haven't heard but might be there is=20 > that with the=20 > >> opaque blob you don't have to document what you are doing. It may=20 > >> just be a convenient rug to sweep things under. > >=20 > > This is what I meant with "abusing," and is our primary concern. I=20 > > have not been in IETF to observe this problem and you are=20 > saying that=20 > > you have not heard so far, but that does not mean that no=20 > one is doing it. > >=20 > > Any more comments? > >=20 > > -acbegen > >=20 > >=20 > >> Regards > >> Marshall > >>=20 > >>=20 > >> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: > >>=20 > >>> Hi all, > >>>=20 > >>> I am trying to identify the pros and cons of using opaque > >> information > >>> for signaling the fec-scheme-specific info. I am aware of=20 > that RMT=20 > >>> adopted the same approach for object transmission > >> information and if a > >>> receiver is not compatible with a particular FEC scheme, > >> then it does > >>> not have to parse that information. > >>>=20 > >>> Yet, I believe it is still important to make a strong case > >> why we put > >>> that information in an opaque form rather than in a=20 > human-readable=20 > >>> form? > >>>=20 > >>> I checked the RFC 5052, however, could not find much detail > >> on this.=20 > >>> One of my concerns is that can the opacity lead to some sort of=20 > >>> abusing? > >>>=20 > >>> Any one with a prior experience on using opaque stuff in=20 > a protocol=20 > >>> header? Comments? > >>>=20 > >>> -acbegen > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Tue Sep 25 02:49:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia4EM-0008DI-0X; Tue, 25 Sep 2007 02:49:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia4EK-0008Cq-OV for fecframe-proto@ietf.org; Tue, 25 Sep 2007 02:49:12 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia4EA-0002eg-Eh for fecframe-proto@ietf.org; Tue, 25 Sep 2007 02:49:08 -0400 Received: from 68.167.206.145 ([68.167.206.145]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Sep 2007 06:49:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 24 Sep 2007 23:48:34 -0700 Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information From: Mark Watson To: "Ali Begen (abegen)" , Marshall Eubanks Message-ID: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf+wavpgjFWvGsiTiqXP6KxZ6fuxQAALTyAAAIA92oACTZ6cAAUNja/ In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54059B649F@xmb-sjc-215.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Well, there are none of either kind yet ;-) The FEC Framework will identify what features an FECFRAME Content Delievery Protocol needs to support to work with the framework. The intention is for us in FECFRAME to define a single Content Delivery Protocol, which can be thought of as the first of many (or at least several). So, the restriction is on future protocols that might want to make use of our framework. If we restrict to text-based protocols, then people who work in an environment in which this is not appropriate would not be able to make use of the framework and this would diminish the value of the work. We could imagine that people in various different standards groups, as well as for non-standard applications might find FECFRANE useful and in some contexts binary protocols are preferred (though often, it seems, for non-technical reasons). Another alternative of asking FEC Schemes to specify both a text and binary version of the scheme-specific information might be overkill. ...Mark On 9/24/07 2:16 PM, "Ali Begen (abegen)" wrote: > Hi Mark, > > Which ones fall out of the set of "CDPs to those within which text-based > encoding is acceptable"? Are there many that do not allow text-baed > encoding? Do we have an approximate number? Of course, if there are many > out there, we should leave it as is. > > -acbegen > > >> -----Original Message----- >> From: Mark Watson [mailto:mark@digitalfountain.com] >> Sent: Monday, September 24, 2007 9:46 AM >> To: Ali Begen (abegen); Marshall Eubanks >> Cc: fecframe-proto@ietf.org >> Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific >> information >> >> All, >> >> "Opaque" was intended to mean that the information carried is >> not _logically_ visible to the carrying protocol. That is, >> the carrying protocol does not place requirements on what can >> or should be carried, or make assumptions about what is >> there, and it delivers the information intact to the >> responsible component at the receiving end. >> >> "Opaque" was not intended to mean that the information is >> deliberately obfuscated. >> >> Also, what we are defining here is specification >> responsibilities, not implementation architecture: it is the >> responsibility of the FEC Scheme specification to define the >> contents of the Scheme-specific information and the >> responsibility of the CDP specification to specify how it is >> carried in a protocol. The two must be decoupled so that CDPs >> are not FEC-scheme-specific and vice versa. This says nothing >> about what implementations are allowed to do with information >> they find in packets: you can implement FEC-scheme-specific >> functionality wherever you like. >> >> The reason for using base64 is that the information is >> defined as a sequence of octets and you cannot carry raw >> octets in SDP. We could, alternatively, require that the >> information is ASCII and then it can be carried directly >> (with certain restrictions). When I said above that the >> protocol could not place requirements on what can be carried, >> this means a *particular* protocol - the FEC Framework itself >> can place whatever requirements we like. >> >> A reason for allowing arbitrary octets is that it allows FEC >> Schemes to define efficient (binary) encodings, which can >> then be used with other CDPs that are themselves binary coded. >> >> So, what it comes down to is that if we ask FEC Schemes to >> define a text-based encoding (which has the advantages >> implied by the mails below), then we restrict the set of >> possible CDPs supported by the framework to those within >> which text-based encoding is acceptable. >> >> I would prefer that we not make this restriction. It is, >> after all, no harder to write code which unpacks a base-64 >> encoded BLOB than to parse a sequence of text "name=value;" pairs. >> >> Regards, >> >> Mark >> >> >> On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >> >>> Hi Marshall, >>> >>> See inline. >>> >>>> Modern Codecs tend to use a lot of opaque information, >> which bugs me, >>>> but we are not going to change that. >>>> >>>> Most streaming codecs make the SDP file from the presented encoded >>>> data to stream. Encoded information might be all sorts of things, >>>> aspect ratios, GOP structure, audio bit rates, stereo vs mono, etc. >>>> If the streamer gets something wrong, it is very hard to fix it in >>>> the SDP file, even if you know what it should be, because it is >>>> opaque. This has caused me considerable pain in the past. >>> >>> I agree, this is a concern. Actually, with the deployment of middle >>> boxes that do some processing on the video streams flowing through >>> them, this is indeed a problem. If the info is in Ascii, it can be >>> repaired somwhere along the path. >>> >>>> I am sure that it more efficient to base 64 encode a 500 character >>>> string rather than send it in Ascii, but this seems a strange >>>> efficiency argument when you are talking about a SDP file >> (sent once) >>>> for a multiple megabit per second video stream. >>> >>> Yes, the coding efficiency for opaque SDP should not be the >> reason we >>> are doing this. >>> >>>> One argument that I haven't heard but might be there is >> that with the >>>> opaque blob you don't have to document what you are doing. It may >>>> just be a convenient rug to sweep things under. >>> >>> This is what I meant with "abusing," and is our primary concern. I >>> have not been in IETF to observe this problem and you are >> saying that >>> you have not heard so far, but that does not mean that no >> one is doing it. >>> >>> Any more comments? >>> >>> -acbegen >>> >>> >>>> Regards >>>> Marshall >>>> >>>> >>>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying to identify the pros and cons of using opaque >>>> information >>>>> for signaling the fec-scheme-specific info. I am aware of >> that RMT >>>>> adopted the same approach for object transmission >>>> information and if a >>>>> receiver is not compatible with a particular FEC scheme, >>>> then it does >>>>> not have to parse that information. >>>>> >>>>> Yet, I believe it is still important to make a strong case >>>> why we put >>>>> that information in an opaque form rather than in a >> human-readable >>>>> form? >>>>> >>>>> I checked the RFC 5052, however, could not find much detail >>>> on this. >>>>> One of my concerns is that can the opacity lead to some sort of >>>>> abusing? >>>>> >>>>> Any one with a prior experience on using opaque stuff in >> a protocol >>>>> header? Comments? >>>>> >>>>> -acbegen >>>>> >>>>> _______________________________________________ >>>>> 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 From fecframe-proto-bounces@ietf.org Tue Sep 25 06:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia85a-00026y-5Y; Tue, 25 Sep 2007 06:56:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia85Z-00026Z-3c for fecframe-proto@ietf.org; Tue, 25 Sep 2007 06:56:25 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia85Y-0004BZ-8L for fecframe-proto@ietf.org; Tue, 25 Sep 2007 06:56:25 -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 8467921; Tue, 25 Sep 2007 06:56:23 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <479CA02C-97E9-4043-B66B-E2A9F702B9C8@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Tue, 25 Sep 2007 06:56:19 -0400 To: Mark Watson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I have no trouble with using binary. I just think that, for fully specified schemes, they have to be fairly clear what the binary means. For the other schemes, I realize that we cannot enforce that. Marshall On Sep 25, 2007, at 2:48 AM, Mark Watson wrote: > Well, there are none of either kind yet ;-) The FEC Framework will > identify > what features an FECFRAME Content Delievery Protocol needs to > support to > work with the framework. > > The intention is for us in FECFRAME to define a single Content > Delivery > Protocol, which can be thought of as the first of many (or at least > several). > > So, the restriction is on future protocols that might want to make > use of > our framework. If we restrict to text-based protocols, then people > who work > in an environment in which this is not appropriate would not be > able to make > use of the framework and this would diminish the value of the work. > We could > imagine that people in various different standards groups, as well > as for > non-standard applications might find FECFRANE useful and in some > contexts > binary protocols are preferred (though often, it seems, for non- > technical > reasons). > > Another alternative of asking FEC Schemes to specify both a text > and binary > version of the scheme-specific information might be overkill. > > ...Mark > > > On 9/24/07 2:16 PM, "Ali Begen (abegen)" wrote: > >> Hi Mark, >> >> Which ones fall out of the set of "CDPs to those within which text- >> based >> encoding is acceptable"? Are there many that do not allow text-baed >> encoding? Do we have an approximate number? Of course, if there >> are many >> out there, we should leave it as is. >> >> -acbegen >> >> >>> -----Original Message----- >>> From: Mark Watson [mailto:mark@digitalfountain.com] >>> Sent: Monday, September 24, 2007 9:46 AM >>> To: Ali Begen (abegen); Marshall Eubanks >>> Cc: fecframe-proto@ietf.org >>> Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific >>> information >>> >>> All, >>> >>> "Opaque" was intended to mean that the information carried is >>> not _logically_ visible to the carrying protocol. That is, >>> the carrying protocol does not place requirements on what can >>> or should be carried, or make assumptions about what is >>> there, and it delivers the information intact to the >>> responsible component at the receiving end. >>> >>> "Opaque" was not intended to mean that the information is >>> deliberately obfuscated. >>> >>> Also, what we are defining here is specification >>> responsibilities, not implementation architecture: it is the >>> responsibility of the FEC Scheme specification to define the >>> contents of the Scheme-specific information and the >>> responsibility of the CDP specification to specify how it is >>> carried in a protocol. The two must be decoupled so that CDPs >>> are not FEC-scheme-specific and vice versa. This says nothing >>> about what implementations are allowed to do with information >>> they find in packets: you can implement FEC-scheme-specific >>> functionality wherever you like. >>> >>> The reason for using base64 is that the information is >>> defined as a sequence of octets and you cannot carry raw >>> octets in SDP. We could, alternatively, require that the >>> information is ASCII and then it can be carried directly >>> (with certain restrictions). When I said above that the >>> protocol could not place requirements on what can be carried, >>> this means a *particular* protocol - the FEC Framework itself >>> can place whatever requirements we like. >>> >>> A reason for allowing arbitrary octets is that it allows FEC >>> Schemes to define efficient (binary) encodings, which can >>> then be used with other CDPs that are themselves binary coded. >>> >>> So, what it comes down to is that if we ask FEC Schemes to >>> define a text-based encoding (which has the advantages >>> implied by the mails below), then we restrict the set of >>> possible CDPs supported by the framework to those within >>> which text-based encoding is acceptable. >>> >>> I would prefer that we not make this restriction. It is, >>> after all, no harder to write code which unpacks a base-64 >>> encoded BLOB than to parse a sequence of text "name=value;" pairs. >>> >>> Regards, >>> >>> Mark >>> >>> >>> On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >>> >>>> Hi Marshall, >>>> >>>> See inline. >>>> >>>>> Modern Codecs tend to use a lot of opaque information, >>> which bugs me, >>>>> but we are not going to change that. >>>>> >>>>> Most streaming codecs make the SDP file from the presented encoded >>>>> data to stream. Encoded information might be all sorts of things, >>>>> aspect ratios, GOP structure, audio bit rates, stereo vs mono, >>>>> etc. >>>>> If the streamer gets something wrong, it is very hard to fix it in >>>>> the SDP file, even if you know what it should be, because it is >>>>> opaque. This has caused me considerable pain in the past. >>>> >>>> I agree, this is a concern. Actually, with the deployment of middle >>>> boxes that do some processing on the video streams flowing through >>>> them, this is indeed a problem. If the info is in Ascii, it can be >>>> repaired somwhere along the path. >>>> >>>>> I am sure that it more efficient to base 64 encode a 500 character >>>>> string rather than send it in Ascii, but this seems a strange >>>>> efficiency argument when you are talking about a SDP file >>> (sent once) >>>>> for a multiple megabit per second video stream. >>>> >>>> Yes, the coding efficiency for opaque SDP should not be the >>> reason we >>>> are doing this. >>>> >>>>> One argument that I haven't heard but might be there is >>> that with the >>>>> opaque blob you don't have to document what you are doing. It may >>>>> just be a convenient rug to sweep things under. >>>> >>>> This is what I meant with "abusing," and is our primary concern. I >>>> have not been in IETF to observe this problem and you are >>> saying that >>>> you have not heard so far, but that does not mean that no >>> one is doing it. >>>> >>>> Any more comments? >>>> >>>> -acbegen >>>> >>>> >>>>> Regards >>>>> Marshall >>>>> >>>>> >>>>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am trying to identify the pros and cons of using opaque >>>>> information >>>>>> for signaling the fec-scheme-specific info. I am aware of >>> that RMT >>>>>> adopted the same approach for object transmission >>>>> information and if a >>>>>> receiver is not compatible with a particular FEC scheme, >>>>> then it does >>>>>> not have to parse that information. >>>>>> >>>>>> Yet, I believe it is still important to make a strong case >>>>> why we put >>>>>> that information in an opaque form rather than in a >>> human-readable >>>>>> form? >>>>>> >>>>>> I checked the RFC 5052, however, could not find much detail >>>>> on this. >>>>>> One of my concerns is that can the opacity lead to some sort of >>>>>> abusing? >>>>>> >>>>>> Any one with a prior experience on using opaque stuff in >>> a protocol >>>>>> header? Comments? >>>>>> >>>>>> -acbegen >>>>>> >>>>>> _______________________________________________ >>>>>> 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 From fecframe-proto-bounces@ietf.org Tue Sep 25 08:23:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9Rp-0002OI-AM; Tue, 25 Sep 2007 08:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9Ro-0002OD-Sz for fecframe-proto@ietf.org; Tue, 25 Sep 2007 08:23:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9Rn-0003sn-Kz for fecframe-proto@ietf.org; Tue, 25 Sep 2007 08:23:28 -0400 X-IronPort-AV: E=Sophos;i="4.20,295,1186372800"; d="scan'208";a="132931420" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Sep 2007 08:23:23 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8PCNReO002928; Tue, 25 Sep 2007 08:23:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PCNPV8008668; Tue, 25 Sep 2007 12:23:29 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 08:23:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Tue, 25 Sep 2007 08:23:21 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6041E8DCC@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf+wavpgjFWvGsiTiqXP6KxZ6fuxQAALTyAAAIA92oAC4TxYA== From: "Rajiv Asati \(rajiva\)" To: "Mark Watson" , "Ali Begen \(abegen\)" , "Marshall Eubanks" , "Rajiv Asati \(rajiva\)" X-OriginalArrivalTime: 25 Sep 2007 12:23:22.0556 (UTC) FILETIME=[DD2D2FC0:01C7FF6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7390; t=1190723007; x=1191587007; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20\(rajiva\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Opacity=20of=20the=20scheme-specif ic=20information |Sender:=20 |To:=20=22Mark=20Watson=22=20, =0A=20=20=20=20=2 0=20=20=20=22Ali=20Begen=20\(abegen\)=22=20, =0A=20=20=20 =20=20=20=20=20=22Marshall=20Eubanks=22=20, =0A=20=2 0=20=20=20=20=20=20=22Rajiv=20Asati=20\(rajiva\)=22=20; bh=frbtwT7SMDwnf6LuqvhOj1zFRT1wMMZHmpVpFCvp8Mk=; b=Scs3lHDsho7afazb2Y6OtKEmHoUTzWqgih0qPcx1YbO3xlf6dW4yQhbditbUEA702TqrwyrT +iXMmRcBy1auDVbhK6gdZQUfXjxnMTsbMncwaBY/473/jY6Vh5weTsNy; Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I agree with Mark.=20 1) It seems optimal to define whatever CDP protocol(s) without assuming a particular FEC scheme specifics. In other words, a given CDP should be able to signal "whatever" FEC scheme info. 2) Additionally, it seems quite beneficial to construct the "FEC specific information" independent of CDP. So, a particular FEC-scheme could construct and structure its information that can be carried by any CDP.=20 This is where the building block approach becomes beneficial. How is one building block constructed is independent of the next building block. We should also consider using something similar to TLVs (type length value).=20 Of course, the (type of) TLVs may be=20 leveraged by more than one FEC-scheme, but they don't have to be. 3) I don't think that sending this info in ASCII is optimal either. While, human-readablity is desired, it is orthagonal to how the FEC-specific information is carried by the CDP.=20 An implementation could include a proper conversion utility (say) to display the info in human-readable form. 4) I am of opinion that the spec should not limit to base64 encoding, since this will also limit the reusing of existing protocol as CDP.=20 Cheers, Rajiv > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Monday, September 24, 2007 12:46 PM > To: Ali Begen (abegen); Marshall Eubanks > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific=20 > information >=20 > All, >=20 > "Opaque" was intended to mean that the information carried is not > _logically_ visible to the carrying protocol. That is, the=20 > carrying protocol > does not place requirements on what can or should be carried, or make > assumptions about what is there, and it delivers the=20 > information intact to > the responsible component at the receiving end. >=20 > "Opaque" was not intended to mean that the information is deliberately > obfuscated. >=20 > Also, what we are defining here is specification responsibilities, not > implementation architecture: it is the responsibility of the=20 > FEC Scheme > specification to define the contents of the Scheme-specific=20 > information and > the responsibility of the CDP specification to specify how it=20 > is carried in > a protocol. The two must be decoupled so that CDPs are not > FEC-scheme-specific and vice versa. This says nothing about what > implementations are allowed to do with information they find=20 > in packets: you > can implement FEC-scheme-specific functionality wherever you like. >=20 > The reason for using base64 is that the information is=20 > defined as a sequence > of octets and you cannot carry raw octets in SDP. We could,=20 > alternatively, > require that the information is ASCII and then it can be=20 > carried directly > (with certain restrictions). When I said above that the=20 > protocol could not > place requirements on what can be carried, this means a *particular* > protocol - the FEC Framework itself can place whatever=20 > requirements we like. >=20 > A reason for allowing arbitrary octets is that it allows FEC=20 > Schemes to > define efficient (binary) encodings, which can then be used=20 > with other CDPs > that are themselves binary coded. >=20 > So, what it comes down to is that if we ask FEC Schemes to define a > text-based encoding (which has the advantages implied by the=20 > mails below), > then we restrict the set of possible CDPs supported by the=20 > framework to > those within which text-based encoding is acceptable. >=20 > I would prefer that we not make this restriction. It is, after all, no > harder to write code which unpacks a base-64 encoded BLOB=20 > than to parse a > sequence of text "name=3Dvalue;" pairs. >=20 > Regards, >=20 > Mark >=20 >=20 > On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: >=20 > > Hi Marshall, > >=20 > > See inline.=20 > >=20 > >> Modern Codecs tend to use a lot of opaque information, which > >> bugs me, but we are not going to change that. > >>=20 > >> Most streaming codecs make the SDP file from the presented > >> encoded data to stream. Encoded information might be all > >> sorts of things, aspect ratios, GOP structure, audio bit > >> rates, stereo vs mono, etc. > >> If the streamer gets something wrong, it is very hard to fix > >> it in the SDP file, even if you know what it should be, > >> because it is opaque. This has caused me considerable pain in > >> the past. > >=20 > > I agree, this is a concern. Actually, with the deployment of middle > > boxes that do some processing on the video streams flowing=20 > through them, > > this is indeed a problem. If the info is in Ascii, it can=20 > be repaired > > somwhere along the path. > > =20 > >> I am sure that it more efficient to base 64 encode a 500 > >> character string rather than send it in Ascii, but this seems > >> a strange efficiency argument when you are talking about a > >> SDP file (sent once) for a multiple megabit per second=20 > video stream. > >=20 > > Yes, the coding efficiency for opaque SDP should not be the=20 > reason we > > are doing this. > >=20 > >> One argument that I haven't heard but might be there is that > >> with the opaque blob you don't have to document what you are > >> doing. It may just be a convenient rug to sweep things under. > >=20 > > This is what I meant with "abusing," and is our primary=20 > concern. I have > > not been in IETF to observe this problem and you are saying that you > > have not heard so far, but that does not mean that no one=20 > is doing it. > >=20 > > Any more comments? > >=20 > > -acbegen > >=20 > >=20 > >> Regards > >> Marshall > >>=20 > >>=20 > >> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: > >>=20 > >>> Hi all, > >>>=20 > >>> I am trying to identify the pros and cons of using opaque > >> information=20 > >>> for signaling the fec-scheme-specific info. I am aware of that RMT > >>> adopted the same approach for object transmission > >> information and if a > >>> receiver is not compatible with a particular FEC scheme, > >> then it does=20 > >>> not have to parse that information. > >>>=20 > >>> Yet, I believe it is still important to make a strong case > >> why we put=20 > >>> that information in an opaque form rather than in a human-readable > >>> form? > >>>=20 > >>> I checked the RFC 5052, however, could not find much detail > >> on this.=20 > >>> One of my concerns is that can the opacity lead to some sort of > >>> abusing? > >>>=20 > >>> Any one with a prior experience on using opaque stuff in=20 > a protocol > >>> header? Comments? > >>>=20 > >>> -acbegen > >>>=20 > >>> _______________________________________________ > >>> FECFRAME-PROTO mailing list > >>> FECFRAME-PROTO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > >>=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 >=20 > _______________________________________________ > FECFRAME-PROTO mailing list > FECFRAME-PROTO@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Tue Sep 25 09:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaArM-0001zE-3x; Tue, 25 Sep 2007 09:53:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaArL-0001yt-Al for fecframe-proto@ietf.org; Tue, 25 Sep 2007 09:53:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaArF-0005yo-3d for fecframe-proto@ietf.org; Tue, 25 Sep 2007 09:53:55 -0400 X-IronPort-AV: E=Sophos;i="4.20,295,1186372800"; d="scan'208";a="132940502" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Sep 2007 09:53:39 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8PDrhnf012155; Tue, 25 Sep 2007 09:53:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PDrfVA010256; Tue, 25 Sep 2007 13:53:43 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:53:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Opacity of the scheme-specific information Date: Tue, 25 Sep 2007 09:53:18 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6041E8E53@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <479CA02C-97E9-4043-B66B-E2A9F702B9C8@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Opacity of the scheme-specific information Thread-Index: Acf/YspTunIKQd7nTfyH8eLRpYlTZAAF/R3A From: "Rajiv Asati \(rajiva\)" To: "Marshall Eubanks" , "Mark Watson" X-OriginalArrivalTime: 25 Sep 2007 13:53:41.0456 (UTC) FILETIME=[7B17B500:01C7FF7B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8865; t=1190728423; x=1191592423; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20\(rajiva\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Opacity=20of=20the=20scheme-specif ic=20information |Sender:=20 |To:=20=22Marshall=20Eubanks=22=20, =0A=20=20=20=20 =20=20=20=20=22Mark=20Watson=22=20; bh=ZYYJxNFReUpGHsV1koiN3d/nZPwNe+u/DsXplAqXTh4=; b=Qd1XD+66qqjgx1hDMng/wu+diS3GeG195lFn4YujJ4lgCFWHU9nGtTOxUVbGMmejzmXPWlxj 1E8knMA1zS/WTWRO6P+cXBdIPb0FQIQCt2GBfGkW+o0zBBcDgu/IBwoF; Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -3.1 (---) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Hi Marshall, I agree.=20 Perhaps, this could be the requirement for the draft to become an I-D. Cheers, Rajiv =20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 > Sent: Tuesday, September 25, 2007 6:56 AM > To: Mark Watson > Cc: fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific=20 > information >=20 > I have no trouble with using binary. I just think that, for fully =20 > specified schemes, they have > to be fairly clear what the binary means. For the other schemes, I =20 > realize that we > cannot enforce that. >=20 > Marshall >=20 > On Sep 25, 2007, at 2:48 AM, Mark Watson wrote: >=20 > > Well, there are none of either kind yet ;-) The FEC Framework will =20 > > identify > > what features an FECFRAME Content Delievery Protocol needs to =20 > > support to > > work with the framework. > > > > The intention is for us in FECFRAME to define a single Content =20 > > Delivery > > Protocol, which can be thought of as the first of many (or at least > > several). > > > > So, the restriction is on future protocols that might want to make =20 > > use of > > our framework. If we restrict to text-based protocols, then people =20 > > who work > > in an environment in which this is not appropriate would not be =20 > > able to make > > use of the framework and this would diminish the value of=20 > the work. =20 > > We could > > imagine that people in various different standards groups, as well =20 > > as for > > non-standard applications might find FECFRANE useful and in some =20 > > contexts > > binary protocols are preferred (though often, it seems, for non-=20 > > technical > > reasons). > > > > Another alternative of asking FEC Schemes to specify both a text =20 > > and binary > > version of the scheme-specific information might be overkill. > > > > ...Mark > > > > > > On 9/24/07 2:16 PM, "Ali Begen (abegen)" wrote: > > > >> Hi Mark, > >> > >> Which ones fall out of the set of "CDPs to those within=20 > which text-=20 > >> based > >> encoding is acceptable"? Are there many that do not allow text-baed > >> encoding? Do we have an approximate number? Of course, if there =20 > >> are many > >> out there, we should leave it as is. > >> > >> -acbegen > >> > >> > >>> -----Original Message----- > >>> From: Mark Watson [mailto:mark@digitalfountain.com] > >>> Sent: Monday, September 24, 2007 9:46 AM > >>> To: Ali Begen (abegen); Marshall Eubanks > >>> Cc: fecframe-proto@ietf.org > >>> Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific > >>> information > >>> > >>> All, > >>> > >>> "Opaque" was intended to mean that the information carried is > >>> not _logically_ visible to the carrying protocol. That is, > >>> the carrying protocol does not place requirements on what can > >>> or should be carried, or make assumptions about what is > >>> there, and it delivers the information intact to the > >>> responsible component at the receiving end. > >>> > >>> "Opaque" was not intended to mean that the information is > >>> deliberately obfuscated. > >>> > >>> Also, what we are defining here is specification > >>> responsibilities, not implementation architecture: it is the > >>> responsibility of the FEC Scheme specification to define the > >>> contents of the Scheme-specific information and the > >>> responsibility of the CDP specification to specify how it is > >>> carried in a protocol. The two must be decoupled so that CDPs > >>> are not FEC-scheme-specific and vice versa. This says nothing > >>> about what implementations are allowed to do with information > >>> they find in packets: you can implement FEC-scheme-specific > >>> functionality wherever you like. > >>> > >>> The reason for using base64 is that the information is > >>> defined as a sequence of octets and you cannot carry raw > >>> octets in SDP. We could, alternatively, require that the > >>> information is ASCII and then it can be carried directly > >>> (with certain restrictions). When I said above that the > >>> protocol could not place requirements on what can be carried, > >>> this means a *particular* protocol - the FEC Framework itself > >>> can place whatever requirements we like. > >>> > >>> A reason for allowing arbitrary octets is that it allows FEC > >>> Schemes to define efficient (binary) encodings, which can > >>> then be used with other CDPs that are themselves binary coded. > >>> > >>> So, what it comes down to is that if we ask FEC Schemes to > >>> define a text-based encoding (which has the advantages > >>> implied by the mails below), then we restrict the set of > >>> possible CDPs supported by the framework to those within > >>> which text-based encoding is acceptable. > >>> > >>> I would prefer that we not make this restriction. It is, > >>> after all, no harder to write code which unpacks a base-64 > >>> encoded BLOB than to parse a sequence of text "name=3Dvalue;" = pairs. > >>> > >>> Regards, > >>> > >>> Mark > >>> > >>> > >>> On 9/24/07 8:55 AM, "Ali Begen (abegen)" wrote: > >>> > >>>> Hi Marshall, > >>>> > >>>> See inline. > >>>> > >>>>> Modern Codecs tend to use a lot of opaque information, > >>> which bugs me, > >>>>> but we are not going to change that. > >>>>> > >>>>> Most streaming codecs make the SDP file from the=20 > presented encoded > >>>>> data to stream. Encoded information might be all sorts=20 > of things, > >>>>> aspect ratios, GOP structure, audio bit rates, stereo vs mono, =20 > >>>>> etc. > >>>>> If the streamer gets something wrong, it is very hard=20 > to fix it in > >>>>> the SDP file, even if you know what it should be, because it is > >>>>> opaque. This has caused me considerable pain in the past. > >>>> > >>>> I agree, this is a concern. Actually, with the=20 > deployment of middle > >>>> boxes that do some processing on the video streams=20 > flowing through > >>>> them, this is indeed a problem. If the info is in Ascii,=20 > it can be > >>>> repaired somwhere along the path. > >>>> > >>>>> I am sure that it more efficient to base 64 encode a=20 > 500 character > >>>>> string rather than send it in Ascii, but this seems a strange > >>>>> efficiency argument when you are talking about a SDP file > >>> (sent once) > >>>>> for a multiple megabit per second video stream. > >>>> > >>>> Yes, the coding efficiency for opaque SDP should not be the > >>> reason we > >>>> are doing this. > >>>> > >>>>> One argument that I haven't heard but might be there is > >>> that with the > >>>>> opaque blob you don't have to document what you are=20 > doing. It may > >>>>> just be a convenient rug to sweep things under. > >>>> > >>>> This is what I meant with "abusing," and is our primary=20 > concern. I > >>>> have not been in IETF to observe this problem and you are > >>> saying that > >>>> you have not heard so far, but that does not mean that no > >>> one is doing it. > >>>> > >>>> Any more comments? > >>>> > >>>> -acbegen > >>>> > >>>> > >>>>> Regards > >>>>> Marshall > >>>>> > >>>>> > >>>>> On Sep 24, 2007, at 10:35 AM, Ali Begen ((abegen)) wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I am trying to identify the pros and cons of using opaque > >>>>> information > >>>>>> for signaling the fec-scheme-specific info. I am aware of > >>> that RMT > >>>>>> adopted the same approach for object transmission > >>>>> information and if a > >>>>>> receiver is not compatible with a particular FEC scheme, > >>>>> then it does > >>>>>> not have to parse that information. > >>>>>> > >>>>>> Yet, I believe it is still important to make a strong case > >>>>> why we put > >>>>>> that information in an opaque form rather than in a > >>> human-readable > >>>>>> form? > >>>>>> > >>>>>> I checked the RFC 5052, however, could not find much detail > >>>>> on this. > >>>>>> One of my concerns is that can the opacity lead to some sort of > >>>>>> abusing? > >>>>>> > >>>>>> Any one with a prior experience on using opaque stuff in > >>> a protocol > >>>>>> header? Comments? > >>>>>> > >>>>>> -acbegen > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > > >=20 >=20 > _______________________________________________ > FECFRAME-PROTO mailing list > FECFRAME-PROTO@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Wed Sep 26 12:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZVt-0006YM-L1; Wed, 26 Sep 2007 12:13:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZVs-0006W2-BI for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:13:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZVq-00044n-IX for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:13:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,302,1186383600"; d="scan'208";a="225549501" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2007 09:13:22 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8QGDMqv023017; Wed, 26 Sep 2007 09:13:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QGDC8J029803; Wed, 26 Sep 2007 16:13:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 09:13:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] SDP params for FEC Date: Wed, 26 Sep 2007 09:13:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CB72@xmb-sjc-215.amer.cisco.com> In-Reply-To: <15B86BC7352F864BB53A47B540C089B6041E8DCE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] SDP params for FEC thread-index: Acftzox5XqhdEoF6Sh2UTLCHdyT+PAGJ+5xwAAInACcCLgCgsACRqA3QAFaRuLA= References: <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> <15B86BC7352F864BB53A47B540C089B6041E8DCE@xmb-rtp-20b.amer.cisco.com> From: "Ali Begen \(abegen\)" To: "Rajiv Asati \(rajiva\)" , "Mark Watson" , X-OriginalArrivalTime: 26 Sep 2007 16:13:17.0997 (UTC) FILETIME=[26502DD0:01C80058] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15944; t=1190823202; x=1191687202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20SDP=20params=20for=20FEC |Sender:=20; bh=yNmVgSwiSb8v9Olbv1CCY7cBt0ta/PEJI2CY7i7lCQU=; b=irLXcDbp9kWlOGox9nHtjTneAIX+uBOW/kT8nkKVMejnrDxrBDLt5vMwiCt50lCgc3mRvwIS 9sRnSkYY7gdm3/1ICDRY0F57uvlVcr5JyxAIsUa1wPP/g7NpzN3mnvEx; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b Cc: X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Any more comments/prior experiences on how we should do the on-demand model? -acbegen=20 > -----Original Message----- > From: Rajiv Asati (rajiva)=20 > Sent: Tuesday, September 25, 2007 5:23 AM > To: Ali Begen (abegen); Mark Watson; fecframe-proto@ietf.org > Subject: RE: [FECFRAME-PROTO] SDP params for FEC >=20 > Hi Ali, >=20 > Please see inline, >=20 > > However, this offer/answer model does not let the receiver=20 > ask for a=20 > > particular FEC scheme from the sender. Does it? This can be=20 > > particularly >=20 > Very good point. Sorry, I wasn't there at the meeting, but I=20 > envision that the CDP would be able to provide this=20 > interaction one way or another. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Ali Begen (abegen) > > Sent: Saturday, September 22, 2007 8:48 PM > > To: Mark Watson; fecframe-proto@ietf.org > > Subject: RE: [FECFRAME-PROTO] SDP params for FEC > >=20 > > Hi everyone, > >=20 > > Regarding the SDP signaling for FEC, I have something missing in my=20 > > notes. As far as I remember, we mainly discussed the offer/answer=20 > > model for our framework. That is, we said that the sender=20 > could offer=20 > > multiple (nested or not) FEC flows (each probably with different=20 > > levels of protection, latency budgets, priority, etc) from=20 > which the=20 > > receiver(s) can select and join the corresponding multicast=20 > group to=20 > > receive the repair packets. > >=20 > > However, this offer/answer model does not let the receiver=20 > ask for a=20 > > particular FEC scheme from the sender. Does it? This can be=20 > > particularly useful in unicast applications (or even in=20 > multicast when=20 > > there is a middle box that manages the sender on behalf of the=20 > > receivers), where the receiver should be able to ask from=20 > the sender=20 > > whatever FEC it wants to receive or the receiver can let the sender=20 > > know how much buffering it can tolerate. Remember the=20 > min_buffer_time=20 > > attribute? The receiver should also be able to set this ... > >=20 > > Can we do this by using the same FEC Framework Configuration=20 > > Information and FEC-Scheme-Specific Information that we use for the=20 > > offer/answer model? What is the best way to execute this=20 > "on-demand"=20 > > model? > >=20 > > Any thoughts? > >=20 > > -acbegen > >=20 > >=20 > >=20 > > > -----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 > > >=20 > > > Ali, > > >=20 > > > I agree. This is an important topic for next week. > > >=20 > > > The current fecframe draft envisages an approach similar to that=20 > > > taken by the FEC Building Block in RMT. In this approach we would=20 > > > define 'containers' > > > for FEC-scheme-specific information, with the intention that each=20 > > > FEC Scheme will define exactly the information it needs=20 > and how it=20 > > > should be coded into the container. > > >=20 > > > Content delivery protocols can then define mechanisms for=20 > carrying=20 > > > these 'containers' in a way which is independent of the=20 > FEC Scheme=20 > > > used. > > >=20 > > > So, the first task is for us to identify which=20 > information is 'FEC=20 > > > Scheme independent', for which we must define specific protocol=20 > > > elements. This includes at least the identity of the FEC Scheme.=20 > > > Then we can define a container for the FEC-Scheme-specific=20 > > > information. In RMT, both kinds of information are referred to as=20 > > > FEC Object Transmission Information. > > >=20 > > > FYI, in DVB they have their own XML-based 'Service Discovery and=20 > > > Selection' > > > scheme which is used to advertise services and communicate the=20 > > > information needed to access the service (e.g. Multicast=20 > address).=20 > > > The FEC information is carried here too. DVB also defines RTSP=20 > > > headers to negotiate this information. > > >=20 > > > ...Mark > > >=20 > > >=20 > > > On 9/10/07 3:18 PM, "Ali Begen (abegen)" wrote: > > >=20 > > > > Hi everyone, > > > >=20 > > > > One topic that I believe we need to discuss is the=20 > definition of=20 > > > > FEC-related parameters within SDP. That is, we need to > > > identify what > > > > kind of FEC parameters need to be conveyed through SDP=20 > 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. > > > >=20 > > > > Some parameters are algorithm-specific (e.g., L and D > > > values for CoP3 > > > > and the seed information for Raptor). We may need these=20 > as well,=20 > > > > however, we should have the right amount of abstraction. > > > >=20 > > > > 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. > > > >=20 > > > > I am hoping we can make a progress in this front and will > > > have a draft > > > > for the December meeting. > > > >=20 > > > > BTW, this work may require a joint collaboration between > > > FECframe and > > > > MMUSIC as well as AVT WGs. > > > >=20 > > > > Ali > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > >> -----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 > > > >>=20 > > > >> 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. > > > >>=20 > > > >> What we need first is for someone to volunteer to outline > > > the current > > > >> relevant work from the other groups, ie RMT > > > >>=20 > > > >> Mark is the primary keeper of our requirements draft=20 > so we need=20 > > > >> confirmation that he will be able to make the interim meeting. > > > >>=20 > > > >> Then with the requirements and an understanding of the current=20 > > > >> relevant work we can begin to address what extensions are > > > necessary > > > >> to meet our goals of FECFrame. > > > >>=20 > > > >> So who is willing and able to provide the outline of > > > current relevant > > > >> work? > > > >>=20 > > > >> Thanks, > > > >> Greg > > > >>=20 > > > >> On 9/2/07, Michael Bany wrote: > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> Do we have any kind of simple agenda? > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> From: Ali Begen (abegen) [mailto:abegen@cisco.com] > > > >>> Sent: Friday, August 31, 2007 6:39 PM > > > >>> To: Michael Bany; Ulas Kozat; Marshall Eubanks > > > >>>=20 > > > >>> Cc: Shiloh Dorgan; Mark Pullen; fecframe-proto@ietf.org > > > >>> Subject: RE: [FECFRAME-PROTO] Re: FECFRAME Design Meeting > > > >> in Fairfax > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> 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. > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> You all have a nice long weekend. > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> - Ali > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> ________________________________ > > > >>>=20 > > > >>>=20 > > > >>> 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 > > > >>>=20 > > > >>> I will be arriving late night Sunday and depart out of > > > >> Reagan National > > > >>> at 5:30 pm on the 18th of September. > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> 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 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> Greetings-- > > > >>>=20 > > > >>> I will be arriving late night Sunday and return back > > on 18th (my > > > >>> reserved flight leaves at 4:45pm from Reagan National). > > > >>>=20 > > > >>> Do we have a tentative schedule/agenda? If the meetings > > > >> will continue > > > >>> until late evening on 18th, I might change my schedule. > > > >>>=20 > > > >>> Ulas > > > >>>=20 > > > >>>=20 > > > >>> On 8/30/07, Marshall Eubanks wrote: > > > >>>=20 > > > >>> OK, having waited for the dust to settle, and having=20 > polled the=20 > > > >>> 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. > > > >>>=20 > > > >>> Mark, Shiloh, can you recommend a nearby hotel ? > > > >>>=20 > > > >>> Also, we will need directions to the exact site of=20 > the meeting. > > > >>>=20 > > > >>> Travel arrangements : > > > >>>=20 > > > >>> Either Dulles (IAD) or National (DCA) airports have easy > > > >> access to > > > >>> GMU in Fairfax, Virginia. > > > >>>=20 > > > >>> National even has subway (Metro) access - > > > >>>=20 > > > >>> http://www.wmata.com/metrorail/systemmap.cfm > > > >>>=20 > > > >>> Blue line to the Orange line, Orange line to Vienna, a > > > >> short cab ride > > > >>> or CUE bus ride to GMU. > > > >>>=20 > > > >>> http://www.fairfaxva.gov/CUEBus/CUEBus.asp > > > >>>=20 > > > >>> I would allow at least an hour for this. A cab ride from > > > >> National or > > > >>> Dulles will cost order $ 30, maybe more from Dulles. > > > >>>=20 > > > >>> 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. > > > >>>=20 > > > >>> http://coyote.gmu.edu/map/fairfax.html > > > >>>=20 > > > >>> 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=20 > > > >>> Washington itself. I would not recommend it unless the > > > flights are > > > >>> really cheap. > > > >>>=20 > > > >>> 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. > > > >>>=20 > > > >>> If people come in early enough Sunday night we should > > > have dinner. > > > >>>=20 > > > >>> Regards > > > >>> Marshall > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> On Aug 22, 2007, at 7:30 AM, Shiloh Dorgan wrote: > > > >>>=20 > > > >>>> Room 320 is reserved for the FECFRAME meeting 17-18=20 > September. > > > >>>> Parking is $8/day. Let me know if anyone needs links for > > > >> directions > > > >>>> or has any questions. > > > >>>>=20 > > > >>>> Shiloh > > > >>>>=20 > > > >>>> Mark Pullen wrote: > > > >>>>> Marshall, > > > >>>>>=20 > > > >>>>> I'm happy to sponsor the meeting 17-18 Sep, on one=20 > 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=20 > 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). > > > >>>>>=20 > > > >>>>> Assuming the above is OK, I'm asking Shiloh to reserve > > > >> a room >> > > > >>> for you (Shiloh, start with 320 ST2 if available). > > > >>>>>=20 > > > >>>>> Mark > > > >>>>>=20 > > > >>>>> On Sun, 19 Aug 2007, Marshall Eubanks wrote: > > > >>>>>=20 > > > >>>>>> Dear Mark; > > > >>>>>>=20 > > > >>>>>> I am trying to find a place for a design team > > meeting for the > > > >>>>>> Fecframe IETF working group. > > > >>>>>>=20 > > > >>>>>> 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. > > > >>>>>>=20 > > > >>>>>> This has the potential to become an essential piece of > > > >> technology > > > >>>>>> underpinning IPTV. > > > >>>>>>=20 > > > >>>>>> 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. > > > >>>>>>=20 > > > >>>>>> At present, I think that everyone is available for > > the entire > > > >>>>>> week, and so room availability could determine >>> > > > >> which two days > > > >>> we meet. > > > >>>>>>=20 > > > >>>>>> Do you think that there is any chance we could=20 > meet at GMU ? > > > >>>>>> Basically, we would need a > > > >>>>>> conference room or classroom for 2 days. Let me know > > > >> what you think. > > > >>>>>>=20 > > > >>>>>> Regards > > > >>>>>> Marshall > > > >>>>>>=20 > > > >>>=20 > > > >>>=20 > > > >>> _______________________________________________ > > > >>> FECFRAME-PROTO mailing list > > > >>> FECFRAME-PROTO@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > > > >>>=20 > > > >>>=20 > > > >>> _______________________________________________ > > > >>> FECFRAME-PROTO mailing list > > > >>> FECFRAME-PROTO@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/fecframe-proto > > > >>>=20 > > > >>>=20 > > > >>=20 > > > >=20 > > > > _______________________________________________ > > > > FECFRAME-PROTO mailing list > > > > FECFRAME-PROTO@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/fecframe-proto > > >=20 > >=20 > > _______________________________________________ > > FECFRAME-PROTO mailing list > > FECFRAME-PROTO@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe-proto > >=20 >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Wed Sep 26 12:37:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZtA-0002zS-D0; Wed, 26 Sep 2007 12:37:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZt8-0002zJ-Vt for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:37:27 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZt7-0004rk-F2 for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:37:26 -0400 Received: by wa-out-1112.google.com with SMTP id k40so4011017wah for ; Wed, 26 Sep 2007 09:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vgLQHlSmk0SrS5JWmJLwQXBbXBgKz48r4vEKE+bCnaA=; b=tGVJtUoJL7l6EzIPjhdcDshIenIqpWUKaB4AybwZmAfERieb7ODCbldzg6ue5s690n4ZVga2FyKvJ+5NI8zrWbbZafFdu7Wdq4L/WEZ/Ad0QoAEgoovfSc0bDYMFBNFtJBsSmsEyYPl3TKTDZJZMX45CmDyKA5XPadWF01XYiig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TiAqIdeeOejRTbsvhzv4zedUjYIaTYdA9y88TszWLTnCDScY0HRLZALdcuqs2diWjp07D6Akf9xr6FnQH51sJqnaoeJ343d6yDkg8gZq2DRaYsaYBFR1WgwSZ1IkK7x1B6yOEtRbz4pA8MEay/ku3qnMU3PjV0NQxwn0MoSk/34= Received: by 10.114.79.1 with SMTP id c1mr1214306wab.1190824643937; Wed, 26 Sep 2007 09:37:23 -0700 (PDT) Received: by 10.114.132.13 with HTTP; Wed, 26 Sep 2007 09:37:23 -0700 (PDT) Message-ID: <38c19b540709260937p28e70f11x13113470ccb227d0@mail.gmail.com> Date: Wed, 26 Sep 2007 09:37:23 -0700 From: "Greg Shepherd" To: "Ali Begen (abegen)" Subject: Re: [FECFRAME-PROTO] SDP params for FEC In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On 9/22/07, Ali Begen (abegen) 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: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)" 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 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 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 12:52:07 2007 Return-path: 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> <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 Subject: Re: [FECFRAME-PROTO] SDP params for FEC Date: Wed, 26 Sep 2007 12:52:00 -0400 To: "Greg Shepherd" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 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)" 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 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 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 12:54:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa9N-0000hZ-Fm; Wed, 26 Sep 2007 12:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa9M-0000hE-SU for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:54:12 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaa9J-0008IQ-8c for fecframe-proto@ietf.org; Wed, 26 Sep 2007 12:54:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="177760142" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2007 09:54:08 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8QGs8jl019356; Wed, 26 Sep 2007 09:54:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8QGs4WO024069; Wed, 26 Sep 2007 16:54:08 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 09:54:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] SDP params for FEC Date: Wed, 26 Sep 2007 09:54:37 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CBCC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540709260937p28e70f11x13113470ccb227d0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] SDP params for FEC thread-index: AcgAW4biFUKj0tScSbq9rvKa9x2QxgAAggEg References: <04CAD96D4C5A3D48B1919248A8FE0D54051FF933@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> <38c19b540709260937p28e70f11x13113470ccb227d0@mail.gmail.com> From: "Ali Begen \(abegen\)" To: "Greg Shepherd" X-OriginalArrivalTime: 26 Sep 2007 16:54:07.0495 (UTC) FILETIME=[DA53E970:01C8005D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14741; t=1190825648; x=1191689648; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20SDP=20params=20for=20FEC |Sender:=20; bh=nQc+noFuBTIv6TOrk7laWTj2yrWYlCeJxZIdWcotrFA=; b=B5B0edmv2BBBUiRWB88igXUpx3XwkL8ehe7IXPGabywKCsBtW+9KFyqgk5tpi6k1gCtOXhK3 CcnaqfV6Zx+eSRnb3z/dYMFrDPdEtsmo0Z0etvdYiNMYaX3vI1JUVtuD; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org > > However, this offer/answer model does not let the receiver=20 > ask for a=20 > > particular FEC scheme from the sender. Does it? This can be=20 > > particularly useful in unicast applications (or even in=20 > multicast when=20 > > there is a middle box that manages the sender on behalf of the=20 > > receivers), >=20 > ...or just the FEC stream on behalf of the sender. > Yes, this is also a valid example. > > where > > the receiver should be able to ask from the sender whatever FEC it=20 > > wants to receive or the receiver can let the sender know how much=20 > > buffering it can tolerate. Remember the min_buffer_time=20 > attribute? The=20 > > receiver should also be able to set this ... >=20 > For the above condition in which the FEC stream is not coming=20 > from the same source as the source data, the initial SDP file=20 > should specify the FEC request address for just such a=20 > handshake IF this is an available option. From there the=20 > interaction is in the protocol. By protocol you mean "SDP Negotiation" (which is still a draft, I believe) or our framework? -acbegen =20 > > Can we do this by using the same FEC Framework Configuration=20 > > Information and FEC-Scheme-Specific Information that we use for the=20 > > offer/answer model? What is the best way to execute this=20 > "on-demand" model? >=20 > Sorry if I'm stating the obvious but I lack the clarity of=20 > any notes from the meeting. :( >=20 > Greg >=20 > > 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=20 > > > taken by the FEC Building Block in RMT. In this approach we would=20 > > > define 'containers' > > > for FEC-scheme-specific information, with the intention that each=20 > > > FEC Scheme will define exactly the information it needs=20 > and how it=20 > > > should be coded into the container. > > > > > > Content delivery protocols can then define mechanisms for=20 > carrying=20 > > > these 'containers' in a way which is independent of the=20 > FEC Scheme=20 > > > used. > > > > > > So, the first task is for us to identify which=20 > information is 'FEC=20 > > > Scheme independent', for which we must define specific protocol=20 > > > elements. This includes at least the identity of the FEC Scheme.=20 > > > Then we can define a container for the FEC-Scheme-specific=20 > > > information. In RMT, both kinds of information are referred to as=20 > > > FEC Object Transmission Information. > > > > > > FYI, in DVB they have their own XML-based 'Service Discovery and=20 > > > Selection' > > > scheme which is used to advertise services and communicate the=20 > > > information needed to access the service (e.g. Multicast=20 > address).=20 > > > The FEC information is carried here too. DVB also defines RTSP=20 > > > headers to negotiate this information. > > > > > > ...Mark > > > > > > > > > On 9/10/07 3:18 PM, "Ali Begen (abegen)" wrote: > > > > > > > Hi everyone, > > > > > > > > One topic that I believe we need to discuss is the=20 > definition of=20 > > > > FEC-related parameters within SDP. That is, we need to > > > identify what > > > > kind of FEC parameters need to be conveyed through SDP=20 > 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=20 > as well,=20 > > > > however, we should have the right amount of abstraction. > > > > > > > > As far as I know, there is not much about this in the=20 > current IETF=20 > > > > documents. DVB is pushing for the hybrid FEC (CoP3 + > > > Raptor), however, > > > > I am not sure what is proposed to negogiate the=20 > algorithm-specific=20 > > > > 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=20 > > > >> 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=20 > so we need=20 > > > >> confirmation that he will be able to make the interim meeting. > > > >> > > > >> Then with the requirements and an understanding of the current=20 > > > >> 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 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=20 > > > >>> (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 wrote: > > > >>> > > > >>> OK, having waited for the dust to settle, and having=20 > polled the=20 > > > >>> 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=20 > 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=20 > > > >>> 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=20 > 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=20 > 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=20 > 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=20 > meeting for the=20 > > > >>>>>> Fecframe IETF working group. > > > >>>>>> > > > >>>>>> Fecframe is a new working group with a charter to >>> >>> > > > >>> ...develop specifications for using >>> forward error=20 > > > >>> 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=20 > the entire=20 > > > >>>>>> week, and so room availability could determine >>> > > > >> which two days > > > >>> we meet. > > > >>>>>> > > > >>>>>> Do you think that there is any chance we could=20 > 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 > > >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Wed Sep 26 13:29:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaagp-0000kU-08; Wed, 26 Sep 2007 13:28:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaagn-0000is-9d for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:28:45 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaagl-0006gY-TV for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:28:45 -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 8472339; Wed, 26 Sep 2007 13:28:43 -0400 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CB72@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D54059B601B@xmb-sjc-215.amer.cisco.com> <15B86BC7352F864BB53A47B540C089B6041E8DCE@xmb-rtp-20b.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D5405A1CB72@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8172F5B1-EE35-44E0-8EC7-F71BBC6D81AB@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] SDP params for FEC Date: Wed, 26 Sep 2007 13:28:39 -0400 To: "Ali Begen \(abegen\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org In Line On Sep 26, 2007, at 12:13 PM, Ali Begen ((abegen)) wrote: > Any more comments/prior experiences on how we should do the on-demand > model? > > -acbegen > >> -----Original Message----- >> From: Rajiv Asati (rajiva) >> Sent: Tuesday, September 25, 2007 5:23 AM >> To: Ali Begen (abegen); Mark Watson; fecframe-proto@ietf.org >> Subject: RE: [FECFRAME-PROTO] SDP params for FEC >> >> Hi Ali, >> >> Please see inline, >> >>> 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 >> >> 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 >> >>> -----Original Message----- >>> From: Ali Begen (abegen) >>> Sent: Saturday, September 22, 2007 8:48 PM >>> To: Mark Watson; fecframe-proto@ietf.org >>> Subject: RE: [FECFRAME-PROTO] SDP params for FEC >>> >>> 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 ... >>> 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 >>> 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 >>> >>> >>> >>>> -----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)" 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 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 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 13:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaand-0005zB-MW; Wed, 26 Sep 2007 13:35:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaanc-0005xN-MC for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:35:48 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaanc-0006vf-GU for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:35:48 -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 8472352 for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:35:48 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: fecframe-proto@ietf.org From: Marshall Eubanks Date: Wed, 26 Sep 2007 13:35:44 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [FECFRAME-PROTO] Encrypted FEC X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Do we want to allow for separately encrypted FEC streams ? I could imagine providing a unprotected stream for free, but only paying subscribers get protection, which is why I asked. Regards Marshall _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Wed Sep 26 13:56:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iab7s-0005YP-2S; Wed, 26 Sep 2007 13:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iab7q-0005XH-MQ for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:56:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iab7k-0001sm-Fi for fecframe-proto@ietf.org; Wed, 26 Sep 2007 13:56:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="402019629" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2007 10:56:27 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8QHuQDs010002; Wed, 26 Sep 2007 10:56:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8QHuDar018196; Wed, 26 Sep 2007 17:56:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 10:56:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [FECFRAME-PROTO] Encrypted FEC Date: Wed, 26 Sep 2007 10:55:18 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> In-Reply-To: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [FECFRAME-PROTO] Encrypted FEC thread-index: AcgAY7KY3qkHOqwhSXeWjAdXXb6DRwAAihJQ References: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> From: "Ali Begen \(abegen\)" To: "Marshall Eubanks" , X-OriginalArrivalTime: 26 Sep 2007 17:56:03.0962 (UTC) FILETIME=[8183C5A0:01C80066] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=972; t=1190829386; x=1191693386; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20\(abegen\)=22=20 |Subject:=20RE=3A=20[FECFRAME-PROTO]=20Encrypted=20FEC |Sender:=20; bh=upG/gCYWF/Bkw+ksr9h0OUGRDXUsy7m5LIpQC9bxsFg=; b=S9XtLnJ2xA/foQl/+SPBfei0SLmSKGBpBqoqD8NjpVKweTVVaJKYPJdgDIfTkj+fdMU7mqy1 Yj35q5uIp47pqp3VfaU+4ne3XU/VkqWbWQ6GOoVr70OEwXw7IJ0tBcIvVV2mbIv54EHAmlqjam QUP96bYghv4f6nFICetKqyUK4=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: fecframe-proto@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Fecframe protocol design team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org This is a valid question and will be used in many networks. Are you asking whether we need to specify the encrypted FEC streams in the SDP somehow?=20 Otherwise, if a handshake on FEC will take place (3-way in your earlier email), I believe the handling of encrypted FEC streams can be achieved thru authentication. -acbegen =20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 > Sent: Wednesday, September 26, 2007 10:36 AM > To: fecframe-proto@ietf.org > Subject: [FECFRAME-PROTO] Encrypted FEC >=20 > Do we want to allow for separately encrypted FEC streams ? >=20 > I could imagine providing a unprotected stream for free, but=20 > only paying subscribers get protection, which is why I asked. >=20 > Regards > Marshall >=20 > _______________________________________________ > FECFRAME-PROTO mailing list > FECFRAME-PROTO@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe-proto >=20 _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto From fecframe-proto-bounces@ietf.org Wed Sep 26 14:17:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabSJ-0001AK-1c; Wed, 26 Sep 2007 14:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabSH-0001A1-SR for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:17:49 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IabSC-0002kG-LM for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:17:49 -0400 Received: by wr-out-0506.google.com with SMTP id 70so870408wra for ; Wed, 26 Sep 2007 11:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=bR0pwBO1ovkuQ1MJQ5hoP6lnIhV11hTXy8QsNS3UR/o=; b=eQktfuaoKvIBL7AfMprVV3WtqbZlpvoa4nD7LEldRCZYkCeyOkRtxlaSFwM6ZtTZ2Ep8LixKV6EjQsYU48aZPi/osa6OSem0yEXw52ABKEHEeNQ1cDgQ5NkShqKScLYW/x7ukpQe7HhJY2prg5KYdtnGimPTX1+uiZP7aaBxsJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XOdjke/jKgp9xbFD1CAwK91Q0tKGuahiQLVtwrX7onPrLwgmGojdw2BzEkJlBQEn0hK6iiLJN/nOEcVH73cAxZM9G/Jx8uTwAIxF+IHrxqQZ/w4XkvytgM6EYB/hVs+u3N5PN1BScdbSx418a9T/CoAUA2U9PFElAvdP8QO5Nuo= Received: by 10.114.190.6 with SMTP id n6mr1393733waf.1190830637807; Wed, 26 Sep 2007 11:17:17 -0700 (PDT) Received: by 10.143.11.11 with HTTP; Wed, 26 Sep 2007 11:17:17 -0700 (PDT) Message-ID: <241bc2150709261117r2c6996c1g1d100e7523a9d090@mail.gmail.com> Date: Wed, 26 Sep 2007 11:17:17 -0700 From: "Ulas Kozat" To: "Ali Begen (abegen)" Subject: Re: [FECFRAME-PROTO] Encrypted FEC In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 References: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839445486==" Errors-To: fecframe-proto-bounces@ietf.org --===============1839445486== Content-Type: multipart/alternative; boundary="----=_Part_10054_17647752.1190830637752" ------=_Part_10054_17647752.1190830637752 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I do not see any particular reason for not allowing separately encrypted FEC streams. But why is this relevant to the framework, e.g., does the application layer or FEC scheme need to coordinate anything with the framework when encryption is used? I do have a question about streaming a scalable video. Do we treat each layer as being served by a separate instantiation of the framework? Or all the layers (I mean core+enhancement) are served by the same instance? I guess it should be separate instantiation. -Ulas On 9/26/07, Ali Begen (abegen) wrote: > > This is a valid question and will be used in many networks. > > Are you asking whether we need to specify the encrypted FEC streams in > the SDP somehow? > > Otherwise, if a handshake on FEC will take place (3-way in your earlier > email), I believe the handling of encrypted FEC streams can be achieved > thru authentication. > > -acbegen > > > > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@multicasttech.com] > > Sent: Wednesday, September 26, 2007 10:36 AM > > To: fecframe-proto@ietf.org > > Subject: [FECFRAME-PROTO] Encrypted FEC > > > > Do we want to allow for separately encrypted FEC streams ? > > > > I could imagine providing a unprotected stream for free, but > > only paying subscribers get protection, which is why I asked. > > > > 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 > ------=_Part_10054_17647752.1190830637752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I do not see any particular reason for not allowing separately encrypted FEC streams. But why is this relevant to the framework, e.g., does the application layer or FEC scheme need to coordinate anything with the framework when encryption is used?

I do have a question about streaming a scalable video. Do we treat each layer as being served by a separate instantiation of the framework? Or all the layers (I mean core+enhancement) are served by the same instance? I guess it should be separate instantiation.

-Ulas

On 9/26/07, Ali Begen (abegen) <abegen@cisco.com> wrote:
This is a valid question and will be used in many networks.

Are you asking whether we need to specify the encrypted FEC streams in
the SDP somehow?

Otherwise, if a handshake on FEC will take place (3-way in your earlier
email), I believe the handling of encrypted FEC streams can be achieved
thru authentication.

-acbegen



> -----Original Message-----
> From: Marshall Eubanks [mailto: tme@multicasttech.com]
> Sent: Wednesday, September 26, 2007 10:36 AM
> To: fecframe-proto@ietf.org
> Subject: [FECFRAME-PROTO] Encrypted FEC
>
> Do we want to allow for separately encrypted FEC streams ?
>
> I could imagine providing a unprotected stream for free, but
> only paying subscribers get protection, which is why I asked.
>
> 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

------=_Part_10054_17647752.1190830637752-- --===============1839445486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe-proto --===============1839445486==-- From fecframe-proto-bounces@ietf.org Wed Sep 26 14:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabl7-00017C-9s; Wed, 26 Sep 2007 14:37:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabl6-000177-Rz for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:37:16 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iabl6-0001wW-CS for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:37:16 -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 8472470; Wed, 26 Sep 2007 14:37:16 -0400 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> References: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Encrypted FEC Date: Wed, 26 Sep 2007 14:37:12 -0400 To: "Ali Begen \(abegen\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org I think that we need to allow for separate encryptions of FEC streams. There is a danger that an attacker could use the main stream and the FEC stream to attack the encryptions. Here is what it says now It is possible that multiple streams with different confidentiality requirements (for example, the streams may be visible to different sets of users) can be FEC protected by a single repair stream. This scenario is not recommended, since resources will be used to distribute and decode data which cannot then be decrypted by at least some receivers. However, in this scenario, confidentiality protection MUST be applied before FEC encoding of the streams, otherwise repair data may be used by a receiver to decode unencrypted versions of source streams which they do not have permissionions to view. If the main stream is not encrypted, there is no security issue, but otherwise I would say that this is not adequate - the FEC needs to be encrypted at _at least_ the level of the original encryption. Obviously, if the encryption scheme "leaks" information, encrypting both FEC and original will leak information faster. But, it is worse that that. Encryption of the same data with two different encryption schemes is notoriously dangerous, and this is close to that (in that you are encrypting plaintext and a known function of the plaintext). If a different encryption scheme is used for the FEC, the combination of the two ciphertexts may thus lead to recovery of the plaintext. Our job is to provide guidance and set limits to scheme creators. I would change the above to read It is possible that multiple streams with different confidentiality requirements (for example, the streams may be visible to different sets of users) can be FEC protected by a single repair stream. This scenario is not recommended, since resources will be used to distribute and decode data which cannot then be decrypted by at least some receivers. Confidentiality protection MAY be applied to FEC streams when the original stream is not, say to allow for a better quality of service to subscribers. If confidentiality protection is applied to the original stream, confidentiality protection MUST be applied before FEC encoding of the streams, otherwise repair data may be used by a receiver to decode unencrypted versions of source streams which they do not have permissionions to view. The confidentiality protection applied to the FEC streams ideally SHOULD be the same protection as that applied to the original stream and MUST in any case be as least as cryptographically "hard" as that applied to the original stream. Identical encryptions (same cipher, same key, same offset of a stream cipher) MUST NOT be applied to the original and FEC streams. Marshall On Sep 26, 2007, at 1:55 PM, Ali Begen ((abegen)) wrote: > This is a valid question and will be used in many networks. > > Are you asking whether we need to specify the encrypted FEC streams in > the SDP somehow? > > Otherwise, if a handshake on FEC will take place (3-way in your > earlier > email), I believe the handling of encrypted FEC streams can be > achieved > thru authentication. > > -acbegen > > > >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme@multicasttech.com] >> Sent: Wednesday, September 26, 2007 10:36 AM >> To: fecframe-proto@ietf.org >> Subject: [FECFRAME-PROTO] Encrypted FEC >> >> Do we want to allow for separately encrypted FEC streams ? >> >> I could imagine providing a unprotected stream for free, but >> only paying subscribers get protection, which is why I asked. >> >> 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 14:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabo1-00039c-3O; Wed, 26 Sep 2007 14:40:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabo0-00039W-5O for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:40:16 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iabnz-00022U-Iq for fecframe-proto@ietf.org; Wed, 26 Sep 2007 14:40:16 -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 8472468; Wed, 26 Sep 2007 14:40:14 -0400 In-Reply-To: References: <09777ABB-C9F1-4C6C-8771-160B7D011469@multicasttech.com> <04CAD96D4C5A3D48B1919248A8FE0D5405A1CC75@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Encrypted FEC Date: Wed, 26 Sep 2007 14:40:10 -0400 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org On Sep 26, 2007, at 2:37 PM, Marshall Eubanks wrote: > I think that we need to allow for separate encryptions of FEC streams. > There is a danger that an attacker could use the main stream and > the FEC stream to attack the encryptions. > > Here is what it says now > > It is possible that multiple streams with different confidentiality > requirements (for example, the streams may be visible to different > sets of users) can be FEC protected by a single repair stream. > This > scenario is not recommended, since resources will be used to > distribute and decode data which cannot then be decrypted by at > least > some receivers. However, in this scenario, confidentiality > protection MUST be applied before FEC encoding of the streams, > otherwise repair data may be used by a receiver to decode > unencrypted > versions of source streams which they do not have permissionions to > view. > > If the main stream is not encrypted, there is no security issue, > but otherwise I would say that this is not adequate - the FEC needs > to be encrypted at _at least_ the level of the original encryption. > > Obviously, if the encryption scheme "leaks" information, encrypting > both FEC and original will leak information faster. But, it is > worse that that. Encryption of the same data with two different > encryption schemes is notoriously dangerous, and this is close to > that (in that you are encrypting plaintext and a known function of > the plaintext). If a different encryption scheme is used for the > FEC, the combination of the two ciphertexts may thus lead to > recovery of the plaintext. > > Our job is to provide guidance and set limits to scheme creators. I > would change the above to read > > It is possible that multiple streams with different confidentiality > requirements (for example, the streams may be visible to different > sets of users) can be FEC protected by a single repair stream. > This > scenario is not recommended, since resources will be used to I would also change this to This scenario SHOULD NOT be done, since resources .... (Note that this also leads to multiple cipher texts for the same plain text attacks.) Marshall > distribute and decode data which cannot then be decrypted by at > least > some receivers. Confidentiality protection MAY be applied to > FEC streams when the original stream is not, say to allow for a > better > quality of service to subscribers. > > If confidentiality protection is applied to the original > stream, confidentiality > protection MUST be applied before FEC encoding of the streams, > otherwise repair data may be used by a receiver to decode > unencrypted > versions of source streams which they do not have permissionions to > view. The confidentiality protection applied to the FEC streams > ideally SHOULD be > the same protection as that applied to the original stream and > MUST in any case be as > least as cryptographically "hard" as that applied to the > original stream. Identical encryptions > (same cipher, same key, same offset of a stream cipher) MUST NOT > be applied to the original and FEC streams. > > Marshall > > > On Sep 26, 2007, at 1:55 PM, Ali Begen ((abegen)) wrote: > >> This is a valid question and will be used in many networks. >> >> Are you asking whether we need to specify the encrypted FEC >> streams in >> the SDP somehow? >> >> Otherwise, if a handshake on FEC will take place (3-way in your >> earlier >> email), I believe the handling of encrypted FEC streams can be >> achieved >> thru authentication. >> >> -acbegen >> >> >> >>> -----Original Message----- >>> From: Marshall Eubanks [mailto:tme@multicasttech.com] >>> Sent: Wednesday, September 26, 2007 10:36 AM >>> To: fecframe-proto@ietf.org >>> Subject: [FECFRAME-PROTO] Encrypted FEC >>> >>> Do we want to allow for separately encrypted FEC streams ? >>> >>> I could imagine providing a unprotected stream for free, but >>> only paying subscribers get protection, which is why I asked. >>> >>> 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 18:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafOv-000680-SW; Wed, 26 Sep 2007 18:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafOu-0005zv-Pq for fecframe-proto@ietf.org; Wed, 26 Sep 2007 18:30:36 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IafOo-0002aY-Gv for fecframe-proto@ietf.org; Wed, 26 Sep 2007 18:30:36 -0400 Received: from 76.222.192.62 ([76.222.192.62]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 22:31:30 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 15:30:13 -0700 Subject: Re: [FECFRAME-PROTO] Encrypted FEC From: Mark Watson To: Marshall Eubanks Message-ID: Thread-Topic: [FECFRAME-PROTO] Encrypted FEC Thread-Index: AcgAjM3nDJCGJmyAEdyQmgAX8sJN9g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Marshall, There are a few different scenarios here, and we have to be careful to distinguish them and explain the considerations separately, because they are very different. Firstly, the idea that the original stream and the FEC protection might have different confidentiality requirements (that some users may be authorised to receive only the original stream and not the FEC), is a new (and interesting) idea which has not been introduced into the discussions before. We need to be careful to describe it and consider it separately, since it arises from a specific user requirement, rather than being just one of several ways to meet the usual confidentiality requirement for the original stream. Secondly, if the above scenario does not apply (users are authorised to receive both streams or neither stream), and when confidentiality protection is applied to the original source, before the FEC is applied, there is no reason to apply confidentiality protection to the FEC stream: the most an attacker could use the FEC stream for would be to recover the protected source stream, which they are assumed to have anyway. As you say, there are some risks associated with applying confidentiality protection _after_ FEC has been applied, since the attacker know about linear relationships within the plaintext. However, I think it is sufficient to require that independent keys are used for the source and FEC data streams in order to avoid this. ...Mark On 9/26/07 11:40 AM, "Marshall Eubanks" wrote: > > On Sep 26, 2007, at 2:37 PM, Marshall Eubanks wrote: > >> I think that we need to allow for separate encryptions of FEC streams. >> There is a danger that an attacker could use the main stream and >> the FEC stream to attack the encryptions. >> >> Here is what it says now >> >> It is possible that multiple streams with different confidentiality >> requirements (for example, the streams may be visible to different >> sets of users) can be FEC protected by a single repair stream. >> This >> scenario is not recommended, since resources will be used to >> distribute and decode data which cannot then be decrypted by at >> least >> some receivers. However, in this scenario, confidentiality >> protection MUST be applied before FEC encoding of the streams, >> otherwise repair data may be used by a receiver to decode >> unencrypted >> versions of source streams which they do not have permissionions to >> view. >> >> If the main stream is not encrypted, there is no security issue, >> but otherwise I would say that this is not adequate - the FEC needs >> to be encrypted at _at least_ the level of the original encryption. >> >> Obviously, if the encryption scheme "leaks" information, encrypting >> both FEC and original will leak information faster. But, it is >> worse that that. Encryption of the same data with two different >> encryption schemes is notoriously dangerous, and this is close to >> that (in that you are encrypting plaintext and a known function of >> the plaintext). If a different encryption scheme is used for the >> FEC, the combination of the two ciphertexts may thus lead to >> recovery of the plaintext. >> >> Our job is to provide guidance and set limits to scheme creators. I >> would change the above to read >> >> It is possible that multiple streams with different confidentiality >> requirements (for example, the streams may be visible to different >> sets of users) can be FEC protected by a single repair stream. >> This >> scenario is not recommended, since resources will be used to > > > I would also change this to > > This scenario SHOULD NOT be done, since resources .... > > (Note that this also leads to multiple cipher texts for the same > plain text attacks.) > > Marshall > >> distribute and decode data which cannot then be decrypted by at >> least >> some receivers. Confidentiality protection MAY be applied to >> FEC streams when the original stream is not, say to allow for a >> better >> quality of service to subscribers. >> >> If confidentiality protection is applied to the original >> stream, confidentiality >> protection MUST be applied before FEC encoding of the streams, >> otherwise repair data may be used by a receiver to decode >> unencrypted >> versions of source streams which they do not have permissionions to >> view. The confidentiality protection applied to the FEC streams >> ideally SHOULD be >> the same protection as that applied to the original stream and >> MUST in any case be as >> least as cryptographically "hard" as that applied to the >> original stream. Identical encryptions >> (same cipher, same key, same offset of a stream cipher) MUST NOT >> be applied to the original and FEC streams. >> >> Marshall >> >> >> On Sep 26, 2007, at 1:55 PM, Ali Begen ((abegen)) wrote: >> >>> This is a valid question and will be used in many networks. >>> >>> Are you asking whether we need to specify the encrypted FEC >>> streams in >>> the SDP somehow? >>> >>> Otherwise, if a handshake on FEC will take place (3-way in your >>> earlier >>> email), I believe the handling of encrypted FEC streams can be >>> achieved >>> thru authentication. >>> >>> -acbegen >>> >>> >>> >>>> -----Original Message----- >>>> From: Marshall Eubanks [mailto:tme@multicasttech.com] >>>> Sent: Wednesday, September 26, 2007 10:36 AM >>>> To: fecframe-proto@ietf.org >>>> Subject: [FECFRAME-PROTO] Encrypted FEC >>>> >>>> Do we want to allow for separately encrypted FEC streams ? >>>> >>>> I could imagine providing a unprotected stream for free, but >>>> only paying subscribers get protection, which is why I asked. >>>> >>>> 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 From fecframe-proto-bounces@ietf.org Wed Sep 26 23:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaje2-000604-8x; Wed, 26 Sep 2007 23:02:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaje1-0005zz-0H for fecframe-proto@ietf.org; Wed, 26 Sep 2007 23:02:29 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaje0-0008Bz-9G for fecframe-proto@ietf.org; Wed, 26 Sep 2007 23:02:28 -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 8473471; Wed, 26 Sep 2007 23:02:26 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [FECFRAME-PROTO] Encrypted FEC Date: Wed, 26 Sep 2007 23:02:18 -0400 To: Mark Watson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-proto-bounces@ietf.org Dear Mark; On Sep 26, 2007, at 6:30 PM, Mark Watson wrote: > Marshall, > > There are a few different scenarios here, and we have to be careful to > distinguish them and explain the considerations separately, because > they are > very different. > > Firstly, the idea that the original stream and the FEC protection > might have > different confidentiality requirements (that some users may be > authorised to > receive only the original stream and not the FEC), is a new (and > interesting) idea which has not been introduced into the > discussions before. > We need to be careful to describe it and consider it separately, > since it > arises from a specific user requirement, rather than being just one of > several ways to meet the usual confidentiality requirement for the > original > stream. > I agree. > Secondly, if the above scenario does not apply (users are > authorised to > receive both streams or neither stream), and when confidentiality > protection > is applied to the original source, before the FEC is applied, there > is no > reason to apply confidentiality protection to the FEC stream: the > most an > attacker could use the FEC stream for would be to recover the > protected > source stream, which they are assumed to have anyway. > I also agree. In this case, I strongly favor the encrypt first, FEC later approach. I was thinking about a modular case where this may not be possible, which was probably lost in my text. > As you say, there are some risks associated with applying > confidentiality > protection _after_ FEC has been applied, since the attacker know about > linear relationships within the plaintext. However, I think it is > sufficient > to require that independent keys are used for the source and FEC data > streams in order to avoid this. Yes. > > ...Mark > Marshall > > > > > On 9/26/07 11:40 AM, "Marshall Eubanks" wrote: > >> >> On Sep 26, 2007, at 2:37 PM, Marshall Eubanks wrote: >> >>> I think that we need to allow for separate encryptions of FEC >>> streams. >>> There is a danger that an attacker could use the main stream and >>> the FEC stream to attack the encryptions. >>> >>> Here is what it says now >>> >>> It is possible that multiple streams with different >>> confidentiality >>> requirements (for example, the streams may be visible to >>> different >>> sets of users) can be FEC protected by a single repair stream. >>> This >>> scenario is not recommended, since resources will be used to >>> distribute and decode data which cannot then be decrypted by at >>> least >>> some receivers. However, in this scenario, confidentiality >>> protection MUST be applied before FEC encoding of the streams, >>> otherwise repair data may be used by a receiver to decode >>> unencrypted >>> versions of source streams which they do not have >>> permissionions to >>> view. >>> >>> If the main stream is not encrypted, there is no security issue, >>> but otherwise I would say that this is not adequate - the FEC needs >>> to be encrypted at _at least_ the level of the original encryption. >>> >>> Obviously, if the encryption scheme "leaks" information, encrypting >>> both FEC and original will leak information faster. But, it is >>> worse that that. Encryption of the same data with two different >>> encryption schemes is notoriously dangerous, and this is close to >>> that (in that you are encrypting plaintext and a known function of >>> the plaintext). If a different encryption scheme is used for the >>> FEC, the combination of the two ciphertexts may thus lead to >>> recovery of the plaintext. >>> >>> Our job is to provide guidance and set limits to scheme creators. I >>> would change the above to read >>> >>> It is possible that multiple streams with different >>> confidentiality >>> requirements (for example, the streams may be visible to >>> different >>> sets of users) can be FEC protected by a single repair stream. >>> This >>> scenario is not recommended, since resources will be used to >> >> >> I would also change this to >> >> This scenario SHOULD NOT be done, since resources .... >> >> (Note that this also leads to multiple cipher texts for the same >> plain text attacks.) >> >> Marshall >> >>> distribute and decode data which cannot then be decrypted by at >>> least >>> some receivers. Confidentiality protection MAY be applied to >>> FEC streams when the original stream is not, say to allow for a >>> better >>> quality of service to subscribers. >>> >>> If confidentiality protection is applied to the original >>> stream, confidentiality >>> protection MUST be applied before FEC encoding of the streams, >>> otherwise repair data may be used by a receiver to decode >>> unencrypted >>> versions of source streams which they do not have >>> permissionions to >>> view. The confidentiality protection applied to the FEC streams >>> ideally SHOULD be >>> the same protection as that applied to the original stream and >>> MUST in any case be as >>> least as cryptographically "hard" as that applied to the >>> original stream. Identical encryptions >>> (same cipher, same key, same offset of a stream cipher) MUST NOT >>> be applied to the original and FEC streams. >>> >>> Marshall >>> >>> >>> On Sep 26, 2007, at 1:55 PM, Ali Begen ((abegen)) wrote: >>> >>>> This is a valid question and will be used in many networks. >>>> >>>> Are you asking whether we need to specify the encrypted FEC >>>> streams in >>>> the SDP somehow? >>>> >>>> Otherwise, if a handshake on FEC will take place (3-way in your >>>> earlier >>>> email), I believe the handling of encrypted FEC streams can be >>>> achieved >>>> thru authentication. >>>> >>>> -acbegen >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marshall Eubanks [mailto:tme@multicasttech.com] >>>>> Sent: Wednesday, September 26, 2007 10:36 AM >>>>> To: fecframe-proto@ietf.org >>>>> Subject: [FECFRAME-PROTO] Encrypted FEC >>>>> >>>>> Do we want to allow for separately encrypted FEC streams ? >>>>> >>>>> I could imagine providing a unprotected stream for free, but >>>>> only paying subscribers get protection, which is why I asked. >>>>> >>>>> 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