Hi Magnus,
> >> 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
That is a bit stretch :)
> capacity information and does a RAMS-R it can severely congest a network
> for a few seconds.
Well we have rules how the server is supposed to send the burst (rate, timing, etc.) documented in the text. It explains what the server does.
> 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.
At the end of intro, I think we can put a few sentences about this.
> >> 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
Actually, I re-read it and it is pretty explicit. The text says it checks client's CNAME (which must be unique). If the server is already processing a request from the same client for the same SSRC, then it is a update. Ow, it is a new request.
I can repeat the above in the text if you think it is necessary.
> 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.
OK what if the text said:
Updated Request: The RTP_Rx MAY send an updated RAMS-R message
(as unicast feedback in the primary multicast RTP session) with
a different value for one or more fields of an earlier RAMS-R
message. The RS MUST be able to detect whether a burst is already planned for or being transmitted to this particular RTP_Rx for this particular media source SSRC. If there is an existing burst planned for or being transmitted, the newly arriving RAMS-R is an updated request; otherwise it is a new request...
> >> 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.
Is the updated text above good for you?
> >
> >> 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.
Personally, this is one what I did initially but then we agreed that one could come up with an alternative method that would produce unique CNAMEs. In other words, methods for producing unique CNAMEs are not unique. So, we rather put the "MUST" in the sentence above not for the specific implementation.
> >> 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.
We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the attack must take place at the same instant (more or less) with the request from the authentic client. One of your family members can probably do this :)
> >> 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.
Things may go wrong anytime, and we do ack that in the paper and have solutions. But if one does not comply with the rules, more things will likely go wrong.
> >> 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.
OK, "packet type" it is then.
> >
> >> 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.
I think we discussed this before. The RAMS-R numbers are no way correlated with the RAMS-I numbers. You are still trying to correlate them.
> 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
The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the server until an updated RAMS-I is received. This is how the protocol works.
> 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.
The server cannot keep state information (i.e. tracking RAMS-R numbers) across different sessions. Furthermore, requests for different streams can go to different servers.
> >> 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.
Ok.
> >> 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.
The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path check). Beyond that is not SRTCP a good solution to avoid this?
-acbegen
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf