|
I agree with your conclusions, giving possible packet lose and
the fact the RS is not required to act on subsequent RMS-R, this would be the best
way to keep it simple. The statement I’m referring to is “In order to limit the complexity, I suggest that we state that the
first received RMS-R triggers a RMS-I. Further RMS-R messages may flow.
Further RMS-I messages may also flow, but there is no explicit requirement to
send an RMS-I in response to a subsequent RMS-R.” I don’t think we need and monotonically increased sequence
number, relaying on that will only complicate the RS decision making and error
handling. Zeev From: Bill Ver Steeg
(versteb) [mailto:versteb at cisco.com] When we added the ability to send more than one RAMS-R
message, we opened up a few design points that we now need to consider. We need to have some nomenclature for describing the
"initial RMS-R" and "subsequent RMS-R", so I will start
with using those words. Better words would be appreciated. The first design point I would like to address is what the RS
is required to do when it receives an RAMS-R for a burst that is already in
flow (aka "subsequent RMS-R"). We stated that the least it could do
was "ignore it". Does this imply that there is no requirement to send
an RMS-I in response to RMS-R messages referencing an in-progress flow? If so,
we should add clarifying text in the document that cautions the RR not to
assume the RAMS-R was dropped. I briefly considered requiring the RS to send a
RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set
of corner cases, and may result in a chatty exchange of messages. We also need to consider how to deterministically
differentiate between the initial RMS-R message and subsequent RMS-R messages,
particularly in the event of packet loss or (unlikely) re-ordering. This
probably leads us to including a monotonically increasing sequence number on
the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the
first one received will trigger the burst. Subsequent RMS-R messages either
change the burst shape or they do not, and they do not trigger additional
messages. Similarly, if the initial RMS-I is dropped it will probably trigger
an additional RMS-R message. Subsequent RMS-I messages will either be received
by the RR or they will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I
have started to go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that
the first received RMS-R triggers a RMS-I. Further RMS-R messages may
flow. Further RMS-I messages may also flow, but there is no explicit
requirement to send an RMS-I in response to a subsequent RMS-R. Bill VerSteeg |