Subject: [Fecframe] Interim Meeting Next Week

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 16 Oct 2008 16:22:33 -0700

The FECFrame working group will be having an interim meeting next month
in San Jose, California. The agenda will be assembled and
sent in a follow-up message.

Starting 1200 Oct 20 - 1700 Oct 22

Location:

Cisco Systems, San Jose, CA

Cisco San Jose, Building 16
http://maps.google.com/maps/ms?client=firefox-a&hl=en&ie=UTF8&msa=0&msid=109496039069852425144.00000112df60cca861566&ll=37.409233,-121.926205&spn=0.031668,0.028968&t=h&z=15

Mon, Oct 20th
Rm. Honolua Bay, 3rd floor
1200-1700

Tues, Oct 21st
Rm. Surfside Jetty, 2nd floor
0900-1700

Wed, Oct 22nd
Rm. Uluwatu, 2nd floor
0900-1700

Local hotel options:
http://maps.google.com/maps?f=q&hl=en&geocode=&q=hotel&sll=37.409233,-121.926205&sspn=0.031668,0.028968&ie=UTF8&ll=37.416527,-121.922193&spn=0.031665,0.028968&t=h&z=15

Agenda:

- Update (and hopefully finalizing) the framework draft + RTP issues
  draft-ietf-fecframe-framework

- Newly adopted DVB AL-FEC drafts (3 of them)
  draft-begen-fecframe-1d2d-parity-scheme-01.txt
  draft-begen-fecframe-interleaved-fec-scheme-00.txt
  draft-ietf-fecframe-dvb-al-fec

- Make progress on the new parity fec draft (not a WG item yet)
  discuss progress/plan to work with SMPTE

- Discuss progress on raptor fec draft
  draft-watson-fecframe-raptor

A social dinner one evening would also be great. Due to the schedule
of some of the attendees I think Monday evening would be best.

See you all soon!,
Greg
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Oct 2008 15:14:39 +0200

>   draft-ietf-fecframe-framework

The issue around the framework that really needs to be discussed is the
transport part. How does one build something that can provide transport
feedback within the framework? Questions are if there is possibility to
have this being used over the regular best-effort Internet and still be
fair. Here I think UDP is the main issue because the framework must
help. If RTP is used, we do have the mechanism in RTP and RTCP. But,
what if it is not RTP.

I see that we probably needs discussion around both best-effort usage
and with some resource reservation or dedicated setup. Anyway there need
to be a fault detection mechanism that prevent errors to result in
persistent problems.

I am sorry that I am not able to be present.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: Mark Watson <[email-masked]>
Date: Mon, 20 Oct 2008 08:55:34 -0700

Magnus,

Do you mean that you think the framework must provide some kind of feedback
mechanism, or are you really concerned that there is some kind of congestion
control (that might use the feedback) for best-effort networks ?

If the former, I'm not sure that the Framework needs to provide this because
feedback is not needed in all cases. Users of the Framework will of course
decide on a case-by-case basis whether they need feedback and define their
own mechanisms.

The feedback problem is actually more general - UDP applications which don't
use FECFRAME need feedback just as much as those which do. One could set up
a new working group on 'UDP feedback for real-time applications' - but
arguable that is just what RTP/RTCP is.

If the latter, then so far we have said that congestion control is the
responsibility of the user of the Framework (the content delivery protocol),
not of the framework. We said that with FECFRAME the application should send
no more than twice as much data as the same application without FECFRAME.

If we think about adding FEC to existing applications that use UDP over the
best-effort internet, those applications (better) already have some form of
congestion control and FECFRAME should not make them move to a different one
just because there are some additional packets being sent containing FEC
data.

Sorry if I've missed some discussions in the past few months. Perhaps there
is something I'm missing in the above.

Btw, I will be at the meeting today.

...Mark

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 20 Oct 2008 17:14:21 -0700

Great progress today! So, a slight change of plans for this week to
accommodate our fit of productivity today:

Tomorrow we will NOT be meeting. The plan is to divide and hide to
work on our respective drafts tomorrow with the updates we agreed upon
today. We will then meet again on Wednesday, starting at 10am, to
review each of the updated drafts.

Today, we had six people in attendance. If others plan on coming for
Wednesday, please tell the virtual attendant in the lobby that you're
here to see Greg Shepherd. She will call my mobile or you can:

1-541-915-4989

Thanks all!,
Greg

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2008 14:39:02 +0100

> control (that might use the feedback) for best-effort networks ?

I would say both.

> decide on a case-by-case basis whether they need feedback and define their

I agree that not all situations require that, but there clearly are
situations that do require them. Thus we need to think on how this can
be solved in the context of the framework.

> arguable that is just what RTP/RTCP is.

RTP is that for a ceratin type of applications. It is not obvious that
all users of Fecframe is RTP/RTCP applications. But clearly I think the
framework needs to consider and document how to use RTP/RTCP for this
purpose.

> no more than twice as much data as the same application without FECFRAME.

Yes, but how do you know that unless you actually have feedback.

> just because there are some additional packets being sent containing FEC

But the issue with FECFrame is that the feedback mechanism that may
exist on the application level is broken by the existence of FEC. If the
upper layer application sees zero packet loss due to the FEC. But in
reality there is 7% packet loss. Then that application may have reacted
but isn't.

> is something I'm missing in the above.

I don't think we have discussed this sufficient. That is why I brought
this up. I am sorry that I wasn't present on the meeting. Because this I
something that I really like to have discussed.

I think the important thing is to see what can easily be provided and
where there need to be hooks for additional information flows to allow
extensions in the future. I don't think we are going to solve all the
issues directly.

Cheers

Magnus Westerlund

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 27 Oct 2008 10:19:58 -0400

Dear Magnus;

> framework needs to consider and document how to use RTP/RTCP for this

I think it is obvious that we would like non-RTP users to use FECFRAME  
if possible.
However, whenever this issue are discussed in depth, we find ourselves  
"bootstrapping to RTP," which
seems out of scope.

In other words, how is feedback to be done ? By something like RTCP RR  
reports. What feedback is needed ?
Packet loss before FEC, packet loss of FEC, packet loss after FEC,  
jitter of source packets, jitter of FEC packets, etc. This implies a  
clock and sequence numbers, and thus something like the RTP header  
and, again, something like RRs. Are streams to be multiplexed ? That  
means something like an SSRC. Etc., etc.

There has never been anything close to a consensus (or, even, IMO, any  
compelling ideas) on how
to do this generically without effectively re-inventing RTP. And, of  
course, any non-RTP scheme is likely to be based on something like WM  
or FM, which have their own headers and clocks and sequence numbers  
and receiver reports, and so need not a generic system, but one  
designed around their capabilities, which is hard to do for a  
proprietary system unless they come to us and ask for help.

My own (non-hat) feeling is that the best we can do here may be an  
informational document on "architectural guidelines" or "design  
guidelines". Or, maybe we could adopt a modular RMT-like approach  
where we assume
the existence of sequence numbers and clocks and SSRCs, etc., and  
describe what to do with them, but I am not
sure what the value of that would be.

Regards
Marshall

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2008 16:13:22 +0100

Marshall Eubanks skrev:
> clock and sequence numbers, and thus something like the RTP header and,
> again, something like RRs. Are streams to be multiplexed ? That means
> something like an SSRC. Etc., etc.
> 
> course, any non-RTP scheme is likely to be based on something like WM or
> FM, which have their own headers and clocks and sequence numbers and
> receiver reports, and so need not a generic system, but one designed
> around their capabilities, which is hard to do for a proprietary system
> unless they come to us and ask for help.
> 
> guidelines". Or, maybe we could adopt a modular RMT-like approach where
> we assume

But, you anyway need to have something that tells one where source
packet belongs in protection scheme. In some cases these can clearly be
reused as a reference framework for losses or even other transport
statistics.

The framework needs to have a reasonable discussion on what is needed
for providing for deployment when not having fully reserved network
resources. Even in such scenarios there usually are good to monitor that
one actually get what one has reserved and that there isn't a fault
somewhere. This is a transport area WG and we need to show that we do
know transport. Even deal reasonably well with the downsides of IP
networks, especially best effort, or semi-best effort networks.

Cheers

Magnus Westerlund