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

> -----Original Message-----
> From: Pal Martinsen (palmarti)
> Sent: Thursday, April 21, 2016 12:46 PM
> To: Suresh Krishnan
> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; Simon Perreault; tram
> mailing list; tram-chairs@ietf.org
> Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-
> data-03: (with DISCUSS and COMMENT)
> 
> 
> > 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. 

STUN retransmissions are paced out using RTO value discussed in RFC5389 and doubled after each retransmission. It looks like a  corner case where the retransmitted packet reaches the server before the previous packet.

-Tiru

> 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
> 
> >
> > ----------------------------------------------------------------------
> > 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