TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant
RFC 4828
Yes
Lars Eggert
No Objection
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ross Callon)
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert
Yes
Ted Hardie Former IESG member
Yes
Yes
(2006-12-13)
Unknown
The document says:
There are many questions about how an adaptive application would use
TFRC-SP that are beyond the scope of this document. In particular,
an application might wish to avoid unnecessary reductions in the
packet size. In this case, an application might wait for some
period of time before reducing the packet size, to avoid an
unnecessary reduction in the packet size. The details of how long
an application might wait before reducing the packet size can be
addressed in documents that are more application-specific.
I understand that these issues are beyond the scope of the document,
but I encourage the investigators looking at codec shifts as an example
of potential packet size changes to look at how FEC strategies associated
with specific codecs interact with this form of adaptation.
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2006-12-14)
Unknown
Section 3.
If the
TFRC implementation knows that the IP layer is using IPv6 instead
of IPv4, then the connection using TFRC-SP MAY use an estimate of
40 bytes instead of 60 bytes for H, for simplicity of
implementation.
It seems the 60 and 40 values should change place in the above sentence.
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2006-12-11)
Unknown
From the SecDir Review by Juergen Quittek: The Security Considerations section claims: > > There are no security considerations introduced in this document. > I can live with this statement. However, it does not seem to be fully consistent with the security considerations in RFC 3448 to which this document refers. The security consideration in RFC 3448 also consider 'attacks' against the fairness performed by a greedy receiver. Consequently, shouldn't this also be an issue here? The question that may be raised in this context is whether or not TFRC-SP makes attacks against fairness more effective. A rogue sender could ignore the 10 ms Min Interval or ignore received feedback. Would a rogue sender be able to get a bigger share of the bandwidth by choosing TFRC-SP instead of choosing another congestion control scheme such as TFRC?