Subject: [FECFRAME-PROTO] DRAFT Narrative Minutes for FECFRAME Design team meeting 5 November 2007

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Nov 2007 18:27:49 -0500

FECFRAME Design team meeting 5 November 2007
Cisco Systems Building 12, James Brown Room
San Jose, California
9:00 AM PST

Attendance :

Rajiv Asati
Michael Bany     [By Teleconference]
Ali Bergen
Marshall Eubanks
Ulias Kozat
Greg Shepherd    [By Teleconference]
Mark Watson

--------

Rajiv : Do we have enough time to discuss the CDP

Marshall : What do you mean by CDP here ?

Ulas : Content Delivery Protocol

Rajiv : Calling it CDP might be overloading it too much.

Ali : It is more than just the signaling part.

Ulas : You mention all of that in the SDP draft.

Ali : SDP is one way to do it. It is not the only way.

Rajiv : There is the protocol itself, the signaling protocol, and its  
transport protocol. SDP does not include a transport protocol.

Marshall : Can the signaling protocol be abstracted from its  
transport protocol,
like SDP ?

Rajiv : I doubt that abstracting the protocol itself would be fair,  
in this context.

I would like to come up with one instance of this signaling protocol,  
as a use case.

Ulas : I am looking at this Figure - Figure 1 in the framework draft  
- I don't think that we have to deal with the IP and UDP layers.

Rajiv : I agree.  What we need is the vehicle that will carry around  
the SDP.

[Mark Watson arrived]

Marshall : OK, let's start with the framework draft.

Mark : So, I went through our notes and went through the framework  
draft. I removed the stuff on SDP. I spent much of the time trying to  
get the references to work [laughter].

The introduction is pretty much unchanged. I added the diffserve code  
point to the end of the architecture review.

In section 5, 5.1 in general - I generalize UDP to transport protocols.

Section 6.5 is where we get into something interesting. We discussed  
tuples and the source UDP port.

Rajiv : A lot of video encoders don't care about the source port.  
They just look at the destination port.

Mark : Because the FEC is between RTP and UDP, you could do other  
things.

Rajiv : The diffserve code point could be part of the tuple, but I  
would make it optional.

Mark : Let me continue through the changes.

Ali : I sent you an email about 2.a and 2.b in the definition of the  
packet flow.

Mark : The definition

2.a tells you what the flow is, and 2.b gives you the name (number).

Ali : We should make it definition or something like that.

Now I understand what Mark means.

Ali : The CDP has to say, this is how I definition the source packet  
flow.

Mark : What I could say is in the case of UDP the flow is uniquely  
identified by a tuple [reads text for this]

[Greg left the call at 10:05 AM PDT]

Rajiv : We are really identifying the tuple and giving it a name -  
that doesn't really mean the entire flow. The tuple is the property  
of the flow but it doesn't mean the entire flow.

Rajiv : Is this identifier carried in the data ?

Mark : It is carried in the source packets, because the tuple is  
implicit in the source packets [i.e., the source address, port, etc.].

The data recovered in the source block is enough to recover the flow,  
but the ID is never included in the packets themselves.

Mark : In the SDP we define the tuple for the source data and the  
tuple for the repair data. I feed those all in and recover more packets.

Rajiv : Would there be a benefit to carrying this in the repair  
packets ?

Mark : No, because there could be more than one source flow

Rajiv : I think it would be good to clarify that.

Marshall : So, if there were multiple source flows, and one repair  
flow for them, all of this would be described in the SDP file ?

Mark : Correct.

Ali : This is described by Figure 3 on page 6 of my draft. I think it  
is really Figure 1.

Mark : Section 6.6 we still must be systematic [?]. Does it still  
have to be non overlapping discrete blocks ?

Ali : Contiguous non overlapping discrete blocks.

Ulas : Equal size

Mark : Not necessarily.

Marshall : What does discrete mean in this context ?

Mark : That is what we decided to get rid of. We couldn't decide what  
it meant.

Ulas : I don't think you need non-contiguous. Are we supposed to  
define here what is suitable for streaming.

Rajiv : I don't think we have the authority to limit the protection  
scheme applied.

Mark : We went back and forth on that in Washington [Fairfax]. One  
issue is congestion control.

Ali : Congestion control with non-systematic flows. {In that you can  
violate the no more than 2 times the underlying data rate.]

Mark : There is a source flow. Whatever the non-systematic case does,  
it knows what the source flow rate is and can limit its output.

Marshall : What if you only wanted to, say, protect MPEG I frames ?  
Why shouldn't we allow that ?

Rajiv : I think that we can't disallow that.

Mark : We have three components, the framework, the scheme and the  
application. The framework expects the application to provide blocks.

We can't define how the application blocks the data. It could be done  
many ways.

Rajiv : I distinguish between 1 and 2 box solutions. In the one box  
solution, the FEC sits at the end of the application. In the two box  
solution, the FEC sits in a separate box receiving packets over some  
network.

Mark : Even in the two box solution, the FEC is doing something  
application driven.

Rajiv : In the one box solution, the FEC has no information about  
layer 2, layer 3, whatever.

Mark : You effectively get the tuple as well. It's like the boundary  
between RTP and UDP. When you send packets to the socket, it has to  
know the tuple information as well.

Marshall : Suppose you wanted to pre compute, in a one box solution,  
the FEC information and include that in the hinted file, so that the  
broadcasters doesn't have to compute anything. I can see people  
wanting to do that.

Rajiv : In the two box solution, the FEC could be application aware  
or it could be not.

Marshall : It could just, say, receive N packets and generate a  
repair packet.

Rajiv : Exactly.

Mark : When we talk about responsibilities, we are talking about  
responsibilities in terms of documents. They have to completely  
specify together the bits one the wire.
That is quite different from how you actually do it. You could maybe  
do it the way described in the documents, or in some completely  
different way.

Rajiv : One question was, does it have to be in contiguous blocks ?  
And the answer is no.
And the second is, do they have to be non-overlapping ?

Ulas : Going back to the document, I think that the discrete block  
captures it.

When I see k packets, I think you input k equal size blocks and you  
do something with it. You have to clearly define what you mean with a  
bit stream.

Mark : This is all about how you allocate functions in the documents.  
They don't have to be contiguous, they don't have to be non-overlapping.

[discussion of stream versus block ciphers]

Rajiv : Do we mean block of packets or a block of bits ?

Mark : Packets

Rajiv : But we don't necessarily mean IP packets

Mark : Right.

Rajiv : Can the packets be IP packets.

Mark : The FEC scheme works above UDP

Rajiv : The FEC has to operate on Layer 4 payloads, instead of packets.

Marshall : I like that.

Rajiv : If we could put a diagram in a figure

Marshall : A flow diagram ?

Rajiv : Yes. What happens at the source and what happens at the  
receiver.

Ulas : What about Section 6.6 then ?

It should be saying that the FEC scheme must be operating on  
payloads. You operate on a bit stream and you get out another stream.

Ali : Source blocks.

Mark : We have the definition of the source block in 6.2 - I can  
generalize that to

[reads the text]

Ali : I thought that we wanted to allow multiple FEC schemes on one  
flow.

Marshall : We did.

Mark : OK.

We were just talking about 6.2, the structure of the source block.

Ulas : Transport packets can be UDP packet or RTP packets. What do we  
mean ?

Rajiv : We can say layer 4

Mark : But that is not so commonly used.

Ulas : I think that your [?]

Mark : Transport packet payload ?

Rajiv : I would just say transport payload. As long as you give an  
example.

Mark : The tuple is a means of defining the flow in terms of the data  
on the wire.

Rajiv : So we should be using the integer value here.

Mark : I think so.

Marshall : How long can the FEC ID be ? Can I just embed the IP  
addresses and ports - the entire tuple, into the scheme ID ?

Mark : The idea with this integer is that we want to give it a tool  
to identify flows.

Rajiv : Should this be mandatory or an option ?

Mark : I think that logically the FEC scheme has to provide this. But  
it is internal to the scheme.

You have to communicate from sender to receiver. In order for the  
scheme to work you either have to embed the entire tuple or a mapping  
from the integer to the tuple.

Mark : Suppose that between the framework and the scheme there are 4  
flows of source data and a repair flow. The FEC scheme at the  
receiver has to recover the 4 flows. There has to be some agreement  
between the source and the receiver

In the FEC mechanism there has to be some information to recover the  
entire flow definition. The integer is just a shorthand.

The way 3GPP did this is to construct a contiguous block of bytes  
which is converted into symbols. In each block there is the flow id  
length and then the payload and then  padding. You don't send the  
padding you just know that it is there. You just pad to the next  
symbol block.

Whenever I receive a packet, the information that I add to the source  
packet tells me where it falls within this block.

In DVB they do things differently as each block is 1316 bytes. The  
number of packets in a block is application specific.

Marshall :

Mark : The CDP has to be able to carry this information

Rajiv : The use of the integer value is local to the receiver.

Mark : Exactly.

Rajiv : Since all of this information is conveyed

Mark : It's there to facilitate information between the source and  
the receiver.

[discussion of the flow id use and necessity]

Rajiv : I am trying to understand the relevance in conveying this  
information from
the source to the receiver.

Mark : These are tools for these implementations to use how they  
want. You need to convey this information from one end to another.  
You need at least to have an ordering.

I recover a packet. I don't get anything for free

Those flow id numbers are in the source block.

Rajiv : My understanding was that we do not carry the flow id in the  
source flow, that you don't change the source flow.

Mark : We do not change the source flow.

We create a source block containing

flow id
length
udp data
padding

All of this is protected.

If the packet is received, this can be recovered. If not, it can be  
recovered from the repair packets.

Rajiv : When the FEC encoding is done if protects the source block.

Ali : I think that this diagram needs to be included in the document.  
This needs to be more clear.

Mark : I think that you should just put in the ordering ?

Marshall : You need to tell the scheme maker that they need to  
restrict the size of the flow identifier

Ali : I am OK with this - it makes life easier.

Rajiv : The length and things like that are part of the scheme.

Ali : It is supposed to be scheme specific.

Mark : What we are trying to do here is to create a modular plug and  
play structure. When you come to implement it you don't have to worry  
about the other pieces.

Ali : We should make life easier for the readers.

Ulas : We should include more and more examples.

Ali : Yes. It might be in this draft or in other drafts, but we need  
to let people know how to connect the pieces.

Mark : I have a paragraph on this now.

I wonder if we should go with your [Rajiv's] comments before lunch ?

Rajiv : There are 37 comments. I don't think we will have time.

[Break for lunch.]

Rajiv : For Internet, we should just say public or private.

Mark : Yep.

Mark : Forward Error Versus Erasure ?

Ali : I think that we should stick to error.

Rajiv : Throughout the document we refer to error.

Should we clarify the distinction between error and erasure ?

For a lot of providers, streaming is something they provide to  
customers not
the multicasts that go to the set-top box.

[discussion of nomenclature of streaming]

Rajiv : Page 3 section 1 - first paragraph last sentence - common  
versus crucial ?

[vote for common]

What does a CDP mean ?

Action : Propose longer more specific definition of CDP.

Action : Define other terms in Comment 6

Rajiv : In 6.5 we define the tuple, we include the diffserve code point

Marshall : A lot of networks might strip out the diffserve code point  
or change it.

Ulan : What is the use of the diffserve code point at the receiver ?

Mark : Sometimes people use that for specific reasons not related to  
QOS.

Ulan : People can abuse any field they want.

Rajiv : Get rid of it.

Ulan : Speaking of figure 1 - should the dashes really cover the  
transport layer and the IP layer.

Mark : You need to specify the transport.

Rajiv : At the same time, you need to specify application.

Mark : Application is everything on top of transport.

Rajiv : It needs to be better defined.

Ulan : Maybe we can put one more box outside of the CDP for the FEC  
Scheme

Rajiv : We still need to define what is the application layer.

Rajiv : Comment 9

Action item : Draw figures illustrating the flows in 5.1 for source  
and receiver operations.

Action item : please use source transport payload and repair packet  
payload consistently

Rajiv : Which piece recovers the packet ?

Mark : The FEC scheme recovers the packet... It sort of implies that  
the framework does it.

Rajiv : That's what I was thinking.

Page 6 - Section 5.1 - 5th para - what if the source packet doesn't  
include the  FEC payload ID ? Is the Source FEC payload ID needed ? I  
thought about it and it is MUST. We need to convey that explicitly  
but I haven't been able to see where.

Maybe we should drop the encoded part.

Mark : We could call it the explicit source payload id ?

Rajiv : That's fair.

Action item : Encoded source payload id to source payload id and  
introduce "explicit source payload id" (Comments 18 and 31.)

Rajiv : It is confusing as to whether the source payload FEC ID is  
mandatory or not.

Comment 28 - section 6.2

Comment 29 : Need to alert the scheme creator of MTU issues with the  
original source IP packet

Does the receiver need to know whether the source FEC payload ID is
encoded in the packet in a separate field or not i.e. conveyed using
existing field(s)?

Mark : This is a property of the FEC scheme. It might be in a  
combination of fields or whatever, but if you understand the scheme  
you will know this.

You define an FEC scheme opaque string which can pass information  
specific to that scheme.

Rajiv : You could define TLV

Mark : You could do this - but the amount of information to  
communicate is really small.

Rajiv : The usefulness is in debugging - it is easy to figure out if  
it is there and how big it is.

Ali : Marshall suggested in Fairfax that they provide open source  
code for the opaque parts.

Marshall : No, I said that for fully specified schemes they would  
have to disclose sufficient information to determine what's in the  
opaque part.

Rajiv : They MUST do that.

Marshall : Yes, they MUST do that.

[break]

SDP draft

new text

The purpose of this document is to introduce the SDP elements that
    MUST be used by the CDPs using the FEC Framework that choose SDP as
    their session description protocol.

Action Item : Some draft must define "fully specified" and "partially  
specified" schemes.

Action Item : Ali should include section numbers for Mark's draft in  
his draft.

Action  Item : Include the generic tag in the framework draft and  
Expand on the meaning of a zero length length source payload fec id  
in section 6.5 bullet 4.

Mark Watson : In the case that the Explicit Source FEC Payload ID is  
used, then only one FEC Scheme MUST be used for this source flow,  
unless the generic tag is used by all of the FEC Schemes for ..

Section 4.2

On FEC grouping attribute : putting 2 or more FEC flows in the same  
group is a means of signaling that either one or the other or  
multiple flows can be used by one receiver, which flows with  
different group attributes should be used in an either / or fashion.

The priority is used to signal the order in which flows should be  
used in case more than one is in an attribute group.

In case priorities exist, MUST join in the order of the priorities of  
the subset of schemes for which it supports.

If you don't specify the priority it is up to the receiver.

Question : Section 4.4 : Do we want to make fec-source-flow   
extensible ?

tag_len is an option but if you don't specify it is zero

should add ABNF to this description

Section 4.5

Is there an upper limit on the number of chars or digits we use here ?

Do we need to partition the fec-scheme case ? Or make allow characters ?
We decided for now digits only, not partitioned, first come first serve.

The scheme ID is the FEC encoding ID. The text of both drafts should  
be searched to make
it scheme ID.

Where is the tuple definition ? This should be described

Marshall : There are issues with adding this information to ASM  
multicasts with multiple sources

Will there be any mention of RTP SSRCs as a means of identifying  
source or repair flows.

We are missing source port right now.

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