Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT)

Hi, Suresh,

On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) <
palmarti@cisco.com> wrote:

>
> > On 21 Apr 2016, at 00:58, Suresh Krishnan <suresh.krishnan@ericsson.com>
> wrote:
> >
> > Suresh Krishnan has entered the following ballot position for
> > draft-ietf-tram-stun-path-data-03: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The RespTransCnt mechanism seems to be a bit fragile and error prone
> > possibly leading to wrong conclusions on the client (please see my
> > example below). If you agree with my assessment, it is probably useful to
> > evaluate whether the added complexity of this RespTransCnt mechanism is
> > worth it for the potentially unreliable results it produces.
> >
> > Consider the following two cases (copy paste with a monospace font for
> > better readability)
> >
> > Case 1: Upstream loss of first "re"transmission
> >
> > |  Upstream loss  |
> > |  Client  Server |
> > +-+-+-+-+-+-+-+-+-+
> > |  1         x    |
> > |                 |
> > |  2         2,1  |
> > |    2,1          |
> >
> > Case 2: Downstream loss of response to first "re"transmission with
> > re-ordering
> >
> > | Downstream loss |
> > |  Client  Server |
> > +-+-+-+-+-+-+-+-+-+
> > |  1         1,2  |
> > |    x            |
> > |  2         2,1  |
> > |    2,1          |
> >
> > How does the client differentiate between these two cases?
> >
> So the problem is that the first retransmit (second transmit) of the STUN
> request arrives before the initial transmit and the response to the initial
> request is lost downstream.
>
> This means not able to distinguish between upstream reordering and
> downstream loss. I do not think adding complexity to solve this is worth
> it. If ICE is using this, it is still valuable information. And once (s)RTP
> starts flowing the reordering will quickly be discovered by out of orer
> packets.
>
> The draft needs to clearly spell out this limitation.
>
> My main worry now is the RTT calculation. Am I right if I assume that the
> packets usually are delayed when reorder, and not magically put in front of
> the queue? If that is the case the RTT measurement should still be ok

Could you take a look at -04, and let us know if the authors have
successfully addressed this Discuss?

Thanks!

Spencer

> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 5: IANA Considerations
> >
> > Shouldn't the range for this option be in the 0x8000-0xBFFF range instead
> > of the 0x8000-0xFFFF range as currently stated by the draft?
>
> Yes. We want it to be part of the IETF Review comprehension-optional range.
>
> >
> > Section 6:
> >
> > I think this requirement is backwards and needs to be reworded.
> >
> > "Unauthenticated STUN message MUST NOT include the PATH-CHARACTERISTIC
> > attribute in order to prevent on-path attacker from influencing
> > decision-making."
> >
> > Suggest rewording to.
> >
> > "The PATH-CHARACTERISTIC attribute MUST NOT be included in
> > unauthenticated STUN messages in order to prevent an on-path attacker
> > from influencing decision-making.”
> >
>
> +1
> > I also agree with Alissa about the vagueness of the attribute name.
> >
> >
> +1
>
> .-.
> Pål-Erik
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>