Re: M2PA Registered Ports

Re: M2PA Registered Ports

*Tentative* TSVWG schedule for IETF 79

TSVWG

I've received the *tentative* WG session slot for our WG. The meeting 
slot is PRELIMINARY and SUBJECT TO CHANGE at the discretion of the 
Secretariat (and IESG) - so DO NOT make travel plans based upon this timing.

>TSVWG Session 1 (2.5 hours)
>Wednesday, Morning Session I 0900-1130
>Room Name: Valley Ballroom A
>----------------------------------------------

James & Gorry

Re: M2PA Registered Ports

Nitin,

See the IANA port number registration for M2PA: www.iana.org

--brian

Nitin Kumar wrote:                            (Fri, 01 Oct 2010 10:01:32)
> 
>    Hello Brian,
>    Thanks for your response.
>    But as mentioned in section 4.1.2 of RFC 4165:
>    "It is necessary for at least one of the endpoints to be listening on
>    the port on which the other endpoint is trying to establish the
>    association.  Therefore, at least one of the port numbers SHOULD be
>    the M2PA registered port."
>    Now when it refers to M2PA registered port, then what port it is
>    actually talking about. I mean which port i call as an M2PA registered
>    port?
>    Regards
>    Nitin

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

I-D Action:draft-ietf-tsvwg-sctp-chunk-flags-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Stream Control Transmission Protocol (SCTP) Chunk Flags Registration
	Author(s)       : M. Tuexen, R. Stewart
	Filename        : draft-ietf-tsvwg-sctp-chunk-flags-02.txt
	Pages           : 8
	Date            : 2010-10-07

This document defines the procedure for registering chunk flags with
the Internet Assigned Numbers Authority (IANA) for the Stream Control
Transmission Protocol (SCTP).  It updates RFC 4960, and also defines
the IANA registry for contents for currently defined chunk types.  It
does not change SCTP in any other way.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-chunk-flags-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: quick failover in SCTP

Hello Nishida-san,

OK, I thought about this some time and think it would be good
to specify a way for a quick failover which can be implemented
at the sender only.

I would like to see some extensions to you suggestion:
* Introduce a threshold (call it PFMR for now).
  Then use
  if (error counter > PMR)
     the path is inactive.
  if (error counter <= PMR) && (error counter > PFMR)
     the path is potentially failed.
  Using PFMR = 0 is what you suggest, PFMR=PMR gives
  the old behavior.

* Specify that you start sending HBs when the path is
  PF. Explicitly allow PFHB.interval=0, which
  I think is a good choice. Maybe we can just remove PFHB.interval.

* Make sure that the following works: The application disabled HBs.
  When a path enters PF (or failed) HB are sent to get the path
  active again. If it is active, no HB should be send (since
  the application disables them).

* Provide a way that applications are not bothered with
  state change notification related to PF when not explicitly
  subscribed.

* Make clear what to do when all paths are PF.

* Make clear what to do when all paths are failed.

What do you think?

Best regards
Michael

On Aug 24, 2010, at 12:04 PM, Yoshifumi Nishida wrote:

> Hello Michael,
> 
> Thanks for your reply. In a nutshell, the difference between PF and PMR=0 are:
>   PF allows SCTP to use another path while SCTP is checking the
> primary path is active or inactive, but don't change the behavior of
> marking the path as inactive.
>   PMR=0 allows SCTP to mark the primary as inactive quickly.
> 
> In my feeling, this will create several differences although it looks similar
> 
> For example, if we use PMR=0, we will need to modify at least the
> following points in the RFC4960
>   1) recommended value for PMR
>   2) behavior in dormant state
>   3) relationship between PMR and AMR
>        RFC4960 states users should avoid having the value of
> 'Association.Max.Retrans' larger than the
>        summation of the 'Path.Max.Retrans'  we'll need to change this part.
> 
> Also, I think we'll need to think about the following points
>   a) Some of current applications or OS local configurations might
> already have specified PMR on their own. If they're not using PMR=0,
> their benefit might be reduced.
>   b) When you have 100Mbps and 1Mbps links and you set 100Mbps as
> primary, everytime packet loss happens on the 100Mbps link, it will
> switch over to the 1Mbps link and have to wait for HeartBeat which is
> likely less frequent (30secs or so). Or, you'll need to add special
> logic here in the spec.
> 
> If we use PF,
>   PF allows SCTP to keep PMR and AMR unchange. Hence, we don't have
> to modify 1) and 3).
>       and issue 2) will be a minor point since we don't change PMR and AMR.
>   Also, PF already has a solution for b) as described in the draft.
> 
> In my view, PMR=0 will requires several "modifications" to the spec
> which might be a bit tricky to understand for implementers while PF
> will requires explicit "addition".
> 
> Thanks,
> --
> Yoshifumi Nishida
> nishida <at> sfc.wide.ad.jp
> 
> 
> 2010/8/23 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>
>> 
>> On Aug 17, 2010, at 12:16 PM, Yoshifumi Nishida wrote:
>> 
>>> Hi folks,
>>> This is a follow-up from the Maastricht meeting.
>>> Preethi and I are proposing quick failover algorithm in SCTP and gave a presentation about this one.
>>> 
>>> In my feeling, the community seems to be positive in enhancing the SCTP standard to some extent to
address this issue.
>>> Also, in my understanding, Michael and Randy suggested that minor updates in the current spec can have
the similar effects as the PF approach can do.
>>> So,  we're going to start with investigating the alternatives for PF approach and would like to know
about the detail of the suggestion.
>>> If Michael and Randy could give us some info about this, we would be grateful very much.
>> Sure.
>> One point is that RFC 4960 does not specify what to do when all paths
>> are INACTIVE. If that happens, the association is called dormant.
>> I think it should be clarified that you still send HB to get a path
>> to ACTIVE again until the association finally fails. This could be
>> handled as an errata, I think.
>> 
>> Now assume that handling of the dormant state.  If I understand PF correctly,
>> you could simply set Path.Max.Retrans to 0 to get the same behavior on the
>> wire as when using PF, or am I missing something? The only difference I see,
>> are the path state change notification sent locally to the user.
>> 
>> But maybe I have overlooked something...
>> 
>> Best regards
>> Michael
>>> Also, if someone who has comments or feedbacks for this, please let us know.
>>> 
>>> Thank you so much.
>>> --
>>> Yoshifumi Nishida
>>> nishida <at> sfc.wide.ad.jp
>>> 
>>> 
>>> 
>> 
> 

Re: quick failover in SCTP

Hello Michael,

Thanks for your response.

2010/10/8 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>:
> Hello Nishida-san,
>
> OK, I thought about this some time and think it would be good
> to specify a way for a quick failover which can be implemented
> at the sender only.

Great!
Please check my comments bellow.

> I would like to see some extensions to you suggestion:
> * Introduce a threshold (call it PFMR for now).
>  Then use
>  if (error counter > PMR)
>     the path is inactive.
>  if (error counter <= PMR) && (error counter > PFMR)
>     the path is potentially failed.
>  Using PFMR = 0 is what you suggest, PFMR=PMR gives
>  the old behavior.

I thought similar thing and I agree with providing a way to disable PF.
I tend to agree with this idea, but one thing I'm not very sure is how
PFMR != 0 && PFMR < PMR can be useful.
If we just want a switch to disable PF, having USE_PF parameter might be enough?
May be Preethi has an opinion on this?

> * Specify that you start sending HBs when the path is
>  PF. Explicitly allow PFHB.interval=0, which
>  I think is a good choice. Maybe we can just remove PFHB.interval.

Hmm. Sorry. I might not quite follow this point.
Does PFHB.interval=0 mean suppress sending HB during PF state?

I agree with all of the following points. I think these are very good points.

> * Make sure that the following works: The application disabled HBs.
>  When a path enters PF (or failed) HB are sent to get the path
>  active again. If it is active, no HB should be send (since
>  the application disables them).
>
> * Provide a way that applications are not bothered with
>  state change notification related to PF when not explicitly
>  subscribed.
>
> * Make clear what to do when all paths are PF.
>
> * Make clear what to do when all paths are failed.
>
> What do you think?
>
> Best regards
> Michael
>
> On Aug 24, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>
>> Hello Michael,
>>
>> Thanks for your reply. In a nutshell, the difference between PF and PMR=0 are:
>>   PF allows SCTP to use another path while SCTP is checking the
>> primary path is active or inactive, but don't change the behavior of
>> marking the path as inactive.
>>   PMR=0 allows SCTP to mark the primary as inactive quickly.
>>
>> In my feeling, this will create several differences although it looks similar
>>
>> For example, if we use PMR=0, we will need to modify at least the
>> following points in the RFC4960
>>   1) recommended value for PMR
>>   2) behavior in dormant state
>>   3) relationship between PMR and AMR
>>        RFC4960 states users should avoid having the value of
>> 'Association.Max.Retrans' larger than the
>>        summation of the 'Path.Max.Retrans'  we'll need to change this part.
>>
>> Also, I think we'll need to think about the following points
>>   a) Some of current applications or OS local configurations might
>> already have specified PMR on their own. If they're not using PMR=0,
>> their benefit might be reduced.
>>   b) When you have 100Mbps and 1Mbps links and you set 100Mbps as
>> primary, everytime packet loss happens on the 100Mbps link, it will
>> switch over to the 1Mbps link and have to wait for HeartBeat which is
>> likely less frequent (30secs or so). Or, you'll need to add special
>> logic here in the spec.
>>
>> If we use PF,
>>   PF allows SCTP to keep PMR and AMR unchange. Hence, we don't have
>> to modify 1) and 3).
>>       and issue 2) will be a minor point since we don't change PMR and AMR.
>>   Also, PF already has a solution for b) as described in the draft.
>>
>> In my view, PMR=0 will requires several "modifications" to the spec
>> which might be a bit tricky to understand for implementers while PF
>> will requires explicit "addition".
>>
>> Thanks,
>> --
>> Yoshifumi Nishida
>> nishida <at> sfc.wide.ad.jp
>>
>>
>> 2010/8/23 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>
>>>
>>> On Aug 17, 2010, at 12:16 PM, Yoshifumi Nishida wrote:
>>>
>>>> Hi folks,
>>>> This is a follow-up from the Maastricht meeting.
>>>> Preethi and I are proposing quick failover algorithm in SCTP and gave a presentation about this one.
>>>>
>>>> In my feeling, the community seems to be positive in enhancing the SCTP standard to some extent to
address this issue.
>>>> Also, in my understanding, Michael and Randy suggested that minor updates in the current spec can have
the similar effects as the PF approach can do.
>>>> So,  we're going to start with investigating the alternatives for PF approach and would like to know
about the detail of the suggestion.
>>>> If Michael and Randy could give us some info about this, we would be grateful very much.
>>> Sure.
>>> One point is that RFC 4960 does not specify what to do when all paths
>>> are INACTIVE. If that happens, the association is called dormant.
>>> I think it should be clarified that you still send HB to get a path
>>> to ACTIVE again until the association finally fails. This could be
>>> handled as an errata, I think.
>>>
>>> Now assume that handling of the dormant state.  If I understand PF correctly,
>>> you could simply set Path.Max.Retrans to 0 to get the same behavior on the
>>> wire as when using PF, or am I missing something? The only difference I see,
>>> are the path state change notification sent locally to the user.
>>>
>>> But maybe I have overlooked something...
>>>
>>> Best regards
>>> Michael
>>>> Also, if someone who has comments or feedbacks for this, please let us know.
>>>>
>>>> Thank you so much.
>>>> --
>>>> Yoshifumi Nishida
>>>> nishida <at> sfc.wide.ad.jp
>>>>
>>>>
>>>>
>>>
>>
>
>

Re: quick failover in SCTP

On Oct 9, 2010, at 12:04 PM, Yoshifumi Nishida wrote:

> Hello Michael,
> 
> Thanks for your response.
> 
> 2010/10/8 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>:
>> Hello Nishida-san,
>> 
>> OK, I thought about this some time and think it would be good
>> to specify a way for a quick failover which can be implemented
>> at the sender only.
> 
> Great!
> Please check my comments bellow.
> 
>> I would like to see some extensions to you suggestion:
>> * Introduce a threshold (call it PFMR for now).
>>  Then use
>>  if (error counter > PMR)
>>     the path is inactive.
>>  if (error counter <= PMR) && (error counter > PFMR)
>>     the path is potentially failed.
>>  Using PFMR = 0 is what you suggest, PFMR=PMR gives
>>  the old behavior.
> 
> I thought similar thing and I agree with providing a way to disable PF.
> I tend to agree with this idea, but one thing I'm not very sure is how
> PFMR != 0 && PFMR < PMR can be useful.
I could image someone wanting to call a path potentially failed
after 2 consecutive timer based retransmission instead of 1.
Just being a bit more conservative. This might help deploying
such a feature in SIGTRAN networks where CMT is not deployed.
For CMT traffic, PFMR==0 is the right choice, I guess.
But I think PF is also very helpful in non-CMT scenarios.
> If we just want a switch to disable PF, having USE_PF parameter might be enough?
> May be Preethi has an opinion on this?
> 
>> * Specify that you start sending HBs when the path is
>>  PF. Explicitly allow PFHB.interval=0, which
>>  I think is a good choice. Maybe we can just remove PFHB.interval.
> 
> Hmm. Sorry. I might not quite follow this point.
> Does PFHB.interval=0 mean suppress sending HB during PF state?
No. I mean just to send them every RTO.
Having a specific interval allows this by setting PFHB.interval=0.
I was just thinking whether one can remove the parameter and send
the HB every RTO (and doubling it)... The same as using PFHB.interval=0.

Does this makes things clearer?

Best regards
Michael
> 
> 
> I agree with all of the following points. I think these are very good points.
> 
>> * Make sure that the following works: The application disabled HBs.
>>  When a path enters PF (or failed) HB are sent to get the path
>>  active again. If it is active, no HB should be send (since
>>  the application disables them).
>> 
>> * Provide a way that applications are not bothered with
>>  state change notification related to PF when not explicitly
>>  subscribed.
>> 
>> * Make clear what to do when all paths are PF.
>> 
>> * Make clear what to do when all paths are failed.
>> 
>> What do you think?
>> 
>> Best regards
>> Michael
>> 
>> On Aug 24, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>> 
>>> Hello Michael,
>>> 
>>> Thanks for your reply. In a nutshell, the difference between PF and PMR=0 are:
>>>   PF allows SCTP to use another path while SCTP is checking the
>>> primary path is active or inactive, but don't change the behavior of
>>> marking the path as inactive.
>>>   PMR=0 allows SCTP to mark the primary as inactive quickly.
>>> 
>>> In my feeling, this will create several differences although it looks similar
>>> 
>>> For example, if we use PMR=0, we will need to modify at least the
>>> following points in the RFC4960
>>>   1) recommended value for PMR
>>>   2) behavior in dormant state
>>>   3) relationship between PMR and AMR
>>>        RFC4960 states users should avoid having the value of
>>> 'Association.Max.Retrans' larger than the
>>>        summation of the 'Path.Max.Retrans'  we'll need to change this part.
>>> 
>>> Also, I think we'll need to think about the following points
>>>   a) Some of current applications or OS local configurations might
>>> already have specified PMR on their own. If they're not using PMR=0,
>>> their benefit might be reduced.
>>>   b) When you have 100Mbps and 1Mbps links and you set 100Mbps as
>>> primary, everytime packet loss happens on the 100Mbps link, it will
>>> switch over to the 1Mbps link and have to wait for HeartBeat which is
>>> likely less frequent (30secs or so). Or, you'll need to add special
>>> logic here in the spec.
>>> 
>>> If we use PF,
>>>   PF allows SCTP to keep PMR and AMR unchange. Hence, we don't have
>>> to modify 1) and 3).
>>>       and issue 2) will be a minor point since we don't change PMR and AMR.
>>>   Also, PF already has a solution for b) as described in the draft.
>>> 
>>> In my view, PMR=0 will requires several "modifications" to the spec
>>> which might be a bit tricky to understand for implementers while PF
>>> will requires explicit "addition".
>>> 
>>> Thanks,
>>> --
>>> Yoshifumi Nishida
>>> nishida <at> sfc.wide.ad.jp
>>> 
>>> 
>>> 2010/8/23 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>
>>>> 
>>>> On Aug 17, 2010, at 12:16 PM, Yoshifumi Nishida wrote:
>>>> 
>>>>> Hi folks,
>>>>> This is a follow-up from the Maastricht meeting.
>>>>> Preethi and I are proposing quick failover algorithm in SCTP and gave a presentation about this one.
>>>>> 
>>>>> In my feeling, the community seems to be positive in enhancing the SCTP standard to some extent to
address this issue.
>>>>> Also, in my understanding, Michael and Randy suggested that minor updates in the current spec can
have the similar effects as the PF approach can do.
>>>>> So,  we're going to start with investigating the alternatives for PF approach and would like to know
about the detail of the suggestion.
>>>>> If Michael and Randy could give us some info about this, we would be grateful very much.
>>>> Sure.
>>>> One point is that RFC 4960 does not specify what to do when all paths
>>>> are INACTIVE. If that happens, the association is called dormant.
>>>> I think it should be clarified that you still send HB to get a path
>>>> to ACTIVE again until the association finally fails. This could be
>>>> handled as an errata, I think.
>>>> 
>>>> Now assume that handling of the dormant state.  If I understand PF correctly,
>>>> you could simply set Path.Max.Retrans to 0 to get the same behavior on the
>>>> wire as when using PF, or am I missing something? The only difference I see,
>>>> are the path state change notification sent locally to the user.
>>>> 
>>>> But maybe I have overlooked something...
>>>> 
>>>> Best regards
>>>> Michael
>>>>> Also, if someone who has comments or feedbacks for this, please let us know.
>>>>> 
>>>>> Thank you so much.
>>>>> --
>>>>> Yoshifumi Nishida
>>>>> nishida <at> sfc.wide.ad.jp
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: quick failover in SCTP

Hi Preethi,

comments in-lne.

Best regards
Michael

On Oct 11, 2010, at 6:02 PM, Preethi Natarajan wrote:

> Michael,
> 
> Thanks for the insightful comments/suggestions. Please see my responses
> below.
> 
> 
> On 10/9/10 5:34 AM, "Michael Tüxen" <Michael.Tuexen <at> lurchi.franken.de>
> wrote:
> 
>> On Oct 9, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>> 
>>> Hello Michael,
>>> 
>>> Thanks for your response.
>>> 
>>> 2010/10/8 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>:
>>>> Hello Nishida-san,
>>>> 
>>>> OK, I thought about this some time and think it would be good
>>>> to specify a way for a quick failover which can be implemented
>>>> at the sender only.
>>>> I would like to see some extensions to you suggestion:
>>>> * Introduce a threshold (call it PFMR for now).
>>>> Then use
>>>> if (error counter > PMR)
>>>>    the path is inactive.
>>>> if (error counter <= PMR) && (error counter > PFMR)
>>>>    the path is potentially failed.
>>>> Using PFMR = 0 is what you suggest, PFMR=PMR gives
>>>> the old behavior.
>>> 
>>> I thought similar thing and I agree with providing a way to disable PF.
>>> I tend to agree with this idea, but one thing I'm not very sure is how
>>> PFMR != 0 && PFMR < PMR can be useful.
>> I could image someone wanting to call a path potentially failed
>> after 2 consecutive timer based retransmission instead of 1.
>> Just being a bit more conservative. This might help deploying
>> such a feature in SIGTRAN networks where CMT is not deployed.
>> For CMT traffic, PFMR==0 is the right choice, I guess.
>> But I think PF is also very helpful in non-CMT scenarios.
> 
> Preethi: Good point. What you are suggesting is a tunable PFMR threshold
> while the current draft always assumes PFMR=0, the most aggressive behavior.
> I don't see how conservative PFMR values can be helpful but it may be a good
> idea to have it just in case.
> 
> 
>>>> * Specify that you start sending HBs when the path is
>>>> PF. Explicitly allow PFHB.interval=0, which
>>>> I think is a good choice. Maybe we can just remove PFHB.interval.
>>> 
>>> Hmm. Sorry. I might not quite follow this point.
>>> Does PFHB.interval=0 mean suppress sending HB during PF state?
>> No. I mean just to send them every RTO.
>> Having a specific interval allows this by setting PFHB.interval=0.
>> I was just thinking whether one can remove the parameter and send
>> the HB every RTO (and doubling it)... The same as using PFHB.interval=0.
> 
> Preethi: I agree. I don't think we need a PFHB.interval. In PF state, HBs
> are sent once every RTO.
> 
> 
>>>> * Make sure that the following works: The application disabled HBs.
>>>> When a path enters PF (or failed) HB are sent to get the path
>>>> active again. If it is active, no HB should be send (since
>>>> the application disables them).
> 
> Preethi: Michael can you clarify this a bit? Looks like we want to confirm
> the following -- apps can control only those HBs that get sent (or not sent)
> during path failure. Apps do not have control over PF HBs; i.e., apps cannot
> enable/disable PF HBs. Is that right?
The socket API allows to configure the HB.interval and to enable/disable
HBs at all. What I suggest is the no matter if the HB are disabled, they
are sent for
* initial path verification (not within the scope of your ID, but noted
  to make things clear)
* getting a path out of potentially failed or failed.
In other words: If the application disables HBs, it only enables the
ones which do path supervision when the path is active and not potentially
failed.

Does this clarify things?
> 
>>>> * Provide a way that applications are not bothered with
>>>> state change notification related to PF when not explicitly
>>>> subscribed.
> 
> Preethi: Good point. To clarify: when PF is on, apps will be notified only
> about PF-to-failure and failure-to-active state changes. Apps will not be
> notified about active-to-PF state change.
Yes. This means that we can enable PF system wide without apps seeing
any difference.
> 
>>>> 
>>>> * Make clear what to do when all paths are PF.
>>>> 
>>>> * Make clear what to do when all paths are failed.
>>>> 
> 
> Preethi: I agree with both points. We can clarify these in the draft.
> 
> Thanks,
> Preethi
> 
> 

RE: TFRC-SP and maximum packet rate

Hi

Sorry about the delay. I have read the report below and it answers a lot of questions. My take is that even
though TFRC may sometimes fail to be 100% fair against TCP it is anyway a lot better than nothing. I am very
interested in your work so if you can send me a draft copy of your work I'd be more than happy.
From my (wireless) perspective I still have some concerns as regards to how fast TFRC can react to the higher
dynamics of for instance 3GPP access like LTE or HSDPA/EUL. I can imagine that one may need an additional
emergency break to cope with this but I have no real work done to prove my point.

Some additional info:
My interest in TFRC is given by the initiative from Google et al to bring real time communication to the web
platform (see http://www.alvestrand.no/mailman/listinfo/rtc-web )
My main interest in this area is congetsion control, a feature that I believe is very important as the real
time media will in this case share the same bottlenecks as TCP. 

/Ingemar 

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:S.Choi <at> cs.ucl.ac.uk] 
> Sent: den 21 september 2010 13:59
> To: Ingemar Johansson S
> Cc: iccrg; tsvwg <at> ietf.org; kohler <at> cs.ucla.edu; floyd <at> icir.org
> Subject: Re: TFRC-SP and maximum packet rate
> 
> Hi,
> 
> > 
> > An issue with modern video codecs is that they produce frames with 
> > larger differences in frame size. For instance I-frames may 
> be so big 
> > that they need to be split up in several packets (for PMTU reasons) 
> > while B- and P-frames are considerably smaller. The effect 
> of this is 
> > that even though the framerate of the video is 30Hz, the 
> packet rate 
> > may be considerably higher when I-frames are transmitted. 
> But I guess 
> > the only way to determine how TFRC-SP works in these cases 
> is to try 
> > it out.
> 
> You are right - the packet size will significantly vary 
> depending on the types of the frame (I, B, or, P) and video 
> content as well. As I said earlier, using TFRC-SP for video 
> streams without a modification may break the (proportional) 
> flow-level fairness when competing with the standard TCP flows.
> 
> There is another similar work that studied TFRC performance 
> with the variable packet sizes - 
> <http://www.icsi.berkeley.edu/ftp/pub/techreports/2000/tr-00-008.pdf>
> This work also mentioned the fairness issues and solve the 
> problem by estimating the mean packet size (assuming PMTU is 
> known a priori).
> 
> However, it is unclear to me as to how much the approximated 
> packet size is meaningful to the calculated send rate 
> (because, the frame sizes are so varying as we know).
> 
> I have an on-going work to solve these problems by 
> re-introducing the TCP-like Ack-clocking mechanism while 
> retaining the smoothness property in the send rate (of 
> course, for the interactive video streaming applications). I 
> should be able to publish the results somewhere in the next 
> month or so. If you are interested, I can send you the draft 
> copy sometimes early next month.
> 
> 
> Cheers,
> Soo-Hyun
> 
> 
> 
> 
>