A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)
RFC 3890
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Allison Mankin; former steering group member) Yes
(Jon Peterson; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Bert Wijnen; former steering group member) (was Discuss) No Objection
(Bill Fenner; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Ned Freed; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Steven Bellovin; former steering group member) (was Discuss) No Objection
There are many other things that can cause erroneous bandwidth estimates, including various forms of tunneling (GRE, IPsec, 6to4) and link-layer encapsulation -- should those be discussed here?
(Ted Hardie; former steering group member) No Objection
I found section 3.5 on the potential interaction with DCCP somewhat lacking. It's clear that using DCCP for real time media will be different in a number of ways from the current flows over UDP, and while it is good that the draft notes the likely difference in header size, it hardly seems like the most important thing to note. The use of different congestion control algorithms seems far more salient; see draft-phelan-dccp-media-00.txt for a description of how TFRC's "contentment penalty" might apply when wrong guesses about available bandwidth come into play. That section of the draft may well date back some time, of course, so it may be unfair to ask for changes, and I certainly wouldn't block the draft for this. But a review by the DCCP folk might imrpove this a good bit; it also might show the need for a separate draft to discuss the DCCP-specific interactions here.
(Thomas Narten; former steering group member) No Objection