Hi,
Responses inline.
Ali C. Begen (abegen) skrev 2010-09-29 17:32:
Hi Magnus,
We are all glad to have you back. Comments are inline. We will get these into
the revision. See inline.
I have the following comments on this document, I think version 7 or 8
was the last version I read before my parental leave.
1. Applicability statement: I think this document should have an
applicability statement making clear that this is only for engineered
environments due to the traffic bursts.
We already put a lot of effort to explain the precautions for using this in
BE networks. I don't think there is a strong argument here that this will
only work in engineered networks. So, personally I don't think we should put
such a statement.
I can agree that it works in certain type of best-effort networks.
However, I don't think at all it is suitable for any best-effort
network. However, as this is mostly bound by the requirement to also
support SSM in the same network the deployment cases are usually meeting
the assumptions about network capacity. However, if one runs an
multicast overlay and a client starts up with not congestion or network
capacity information and does a RAMS-R it can severely congest a network
for a few seconds.
There are a number of assumptions in where this will work most of the
time and with very few exceptions have any large scale impact on the
network. I think these should be documented in an applicability statement.
2. Section 6.2, bullet 5: I don't think the document is clear on that
the BRS is expected to determine if a RAMS-R is a retransmission or an
update based on if any content of the message has been changed.
The statement over there implies this. And naturally it is the server's job
to figure that out. Based on this discussion, we even wrote the new CNAME
guidelines document so that the server's job would get easier.
Exactly the document implies rather than being explicit. I am not
certain that I have understood all the mechanism you expect me to use to
determine if a RAMS-R is a retransmission or a new request. Based on
that it is uncertain for a client to know what effect an RAMS-R message
will have. I also think it makes sense to mandate that servers do have
retransmission detection, otherwise you end up in a situation where a
client don't dare retransmit a request for the fear of getting two bursts.
3. I worried that what is intended to be an RAMS-R update from the
client will be interpreted as new RAMS-R request. The reason is the only
that separates these two cases are timing, does it arrive before the
burst ends or not. Relying on this heuristics is quite weak and error
prone. I still wished that an sequence number had been added to RAMS-R.
I gave enough arguments why we should not use a seqnum for the RAMS-R
messages earlier. It is not justified IMO. Based on the SSRC of the primary
and the requesting client's CNAME, things are pretty straightforward.
Yes, I know I am in the rough here. From my perspective, it makes the
use of update RAMS-R uncertain to use. Maybe not a big issue if most
doesn't implement updates. But if one finds need for it then there will
be issues. Consider the AD and IESG notified about the potential issue.
4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally
unique CNAME identifier."
I don't think this is a statement that can either be fulfilled nor
tested. You can mandate a method for selecting CNAMEs that has low risk
of producing CNAME collisions, but nothing can guarantee it unless a
entity is coordinating the CNAME space for all clients. Can you mandate
the method instead?
The new CNAME draft has ways to ensure they are unique. If the client uses
one of them, we are all set.
Yes, but in that case mandate the implementation and usage of one of
these instead of statement that can't be ensured.
If I understand the impact of a CNAME collision is that the collision
clients request will be mixed up, for example terminating each others
request, or update the values in the RAMS-R.
When they are unique, this won't happen.
Just checking, but if that is the case then I am missing a discussion of
hijacking attacks in the security consideration section by guessing your
targets CNAME.
5. Section 6.4 and others: The draft has a tendency of formulating
itself as everything is guaranteed to work as long as one keep within
given limits for bandwidth etc. An example from Section 7.2 Max Receive
Bitrate TLV:
We don't assume things will sure work or guarantee that they will work if
everything is satisfied. These are simple rules that both sides must comply
with.
No, but a certain view point is clear in the text. Lets call it
optimistic that it will work, while I would write from a more
pessimistic view.
If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value.
Otherwise, congestion and packet loss may occur.
The last sentence I would formulate as:
"Otherwise, congestion and packet loss are much likelier to occur"
How about "more likely to occur"?
Sure.
Even if one stays within this value congestion and packet loss may
occur. This is not the only case, but when I actually decided this seems
to be an issue, I hadn't taken note of all examples I seen.
6. Section 7:
Each feedback message has a fixed-length field for version, padding,
feedback message type (FMT), payload type (PT), length, SSRC of
packet sender, SSRC of media sender as well as a variable-length
field for feedback control information (FCI).
What is called "Payload type" is actually "Packet Type" in RTCP packet
headers.
We followed the definition from 4585 but "packet type" makes more sense to me
as well.
Well, section 6.1 of RFC 4585 is wrong.
7. Section 7.3:
"The MSN value SHALL
be set to zero only when a new RAMS request is received."
How is that actually known? And why reset it at all? Why not increase if
for each new RAMS-I message with new content, independently if it is an
update or a new request.
If this is relating to a new burst request, then it is reset. Ow, what is the
point of having a seqnum? If something has changed compared to the previous
RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same.
I fully agree with the need for separating retransmissions from updates.
However, I wonder over the reset of the field for each new RAMS-R. It
appears to me to be more robust to simply increment it rather than
reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0.
Then a RAMS-R(2) that is intended to be an update but becomes an new
request results in an RAMS-I with MSN = 0. The client will not know if
this is an retransmission of RAMS-R(1) info. The updated should result
in MSN=1. So without comparing the RAMS-I you can't determine if there
is new information. Going my way (no reset) does not allow a client to
determine if an RAMS-R was treated as update or new request, but it will
correctly know that it is new RAMS-I information.
8. Section 7.3:
"When the RTP_Rx receives a RAMS-I message with a response code
that it does not understand, the RTP_Rx MUST send a RAMS-T message
immediately to the BRS."
Which media sender SSRC should the client direct this request to if it
hasn't been signalled in SDP nor any RTP/RTCP packets received?
The rules in the RAMS-T section applies. You received a RAMS-I so you know
the SSRC.
Yes, you are correct. My mistake.
9. Section 7.3, Media Sender SSRC TLV:
" While this
information is already available in the message header, it can be
useful to repeat it in an explicit field."
This sentence seems out of place compared to the rest of the text.
If I recall correctly, this was something you asked for. I am not sure
whether there is a better place to put it. Maybe in parentheses?
I think we can remove that sentence. I think you now have text making
clear when it needs to be included and when it shouldn't.
10. Section 7.3, RTP Seqnum of the First Packet TLV:
How is this TLV bound to the SSRC number if is for? This is not
explicitly explained.
What do you mean? The SSRC comes from the RAMS-I's SSRC. There is one (not
multiple) stream per RAMS-I.
Yes, something that I apparently have forgotten.
11. Section 7.4:
Each of these RAMS-T messages has
the appropriate media sender SSRC populated in its message header.
Instead of writing "appropriate" cant you simply write " Each of these
RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of
the Media Stream to be terminated."
Good suggestion.
12. Section 8.3:
"This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions."
Can you make clear that this an example of an SDP to be provided to a
client?
OK.
13. Section 9, bullet b:
Be configured to forward certain ports (e.g., using HTML
configuration and UPnP IGD [UPnP-IGD]).
Shouldn't the "and" be an "or"?
Yes, good catch.
14. Section 10:
Shouldn't the security consideration make it clear that RAMS-R are
especially suspectible to Replay attacks as there is no information in
the packet that one can use to detect that it is out of sequence.
There is a wording about this in that section (which simply refers the reader
to 5760). Are you considering a RAMS-specific replay attack here?
Yes, I am considering that it is easy to target RAMS-R specifically for
an replay attack. Especially when sent in a reduced size RTCP packet
only containing RAMS-R and SDES CNAME. That has no time specific
information and all replay detection must happen in the security protocol.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto:
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf