[Gen-art] Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07

Hi, Jerry,

Definitely headed the right direction. Do the right thing - and thanks.

Spencer

From: "ASH, GERALD R (JERRY), ATTLABS" <gash@att.com>

Hi Spencer,

Thanks a lot for the quick reply.  Please see below. 

> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] 
> Subject: Re: Gen-ART Last Call Review of 
> draft-ietf-avt-hc-over-mpls-protocol-07
> 
> Hi, Jerry,
> 
> This is easier than it should be... slicing down through the stuff we 
> already worked out (if I deleted it, I agree with your plan)...
> 
> >    option is the same for both IPCP and IPV6CP.  This configuration
> >    option MUST be included for ECRTP, CRTP and IPHC PW 
> >    types and MUST NOT be included for ROHC PW types.
> >
> > Spencer: Is it obvious what the decompressor does if it sees this
> > configuration option for ROHC PW types? It may be - I'm just
> > asking. I'd
> > have the same question elsewhere (in 5.2.2, for example), but
> > will only ask it here.
> 
> Yes.  The corresponding text for the ROHC configuration option is
> specified in Section 5.2.5.  In other sections we specify that the
> configuration options are only applicable to specific header 
> compression formats, e.g., as in Section 5.2.2 for cRTP.
> 
> Spencer: there was this theory about testing TCP with "kamikaze" or 
> "Christmas tree" packets (you set all the options to "1", 
> whether that makes 
> sense or not, and see what the other guy does). I think I'm 
> asking "what 
> SHOULD happen if the decompressor sees a packet like this". 
> I'm wondering if we still worry about things like this...

You make a very good point, error legs of course are critical for
whatever erroneous configuration or coding may occur.  We can specify
something like this in Section 5.2.1 (Configuration Option Format)

  "... This configuration
   option MUST be included for ECRTP, CRTP and IPHC PW types and MUST
   NOT be included for ROHC PW types.  A decompressor MUST reject this
   option (if misconfigured) for ROHC PW types and send an explicit
   error message to the compressor [RFC3544]."

> >    and loss, it is still the protocol of choice in many
> >    cases.  In these
> >    circumstances, it must be implemented and deployed with 
> >    care.  IPHC
> >    should use TCP_NODELTA, ECRTP should send absolute values, ROHC
> >    should be adapted as discussed in [RFC4224].  An evaluation and
> >    simulation of ECRTP and ROHC reordering is given in 
> >    [REORDER-EVAL].
> >
> > Spencer (Probably a Nit): It wasn't obvious to me whether these
> > recommendations are sufficient to "implement and deploy 
> > with care", or
> > whether additional precautions must be taken. Even putting these
> > recommendations in a numbered list immediately after
> > "deployed with care"
> > would be sufficient, if these recommendations are sufficient.
> 
> This goes back to a discussion with Allison Mankin RE CRTP issues
> discussed icw RFC 4446.  There was no further list of recommendations
> out of that discussion, rather, the point is that in packet-lossy
> environments, for example, CRTP may not work well and ECRTP 
> may perform
> better.  Some folks felt that CRTP should be excluded because of that
> problem.  There were, however, other concerns raised on 
> deploying ECRTP
> (e.g., CRTP is already widely deployed, plus other reasons).
> 
> Spencer: would it be appropriate to say "implement and deploy 
> with care:", 
> and then put the recommendations in a numbered list? My 
> concern was pretty 
> basic - if I follow these recommendations, do I still have a 
> problem, or am OK?

There really isn't any list of 'recommendations' as to how to 'deploy
(CRTP) with care' in the case of lossy links and reordering issues, that
phrasing should be removed as misleading.  Rather, we can further
explain the issue with CRTP, as described in [RFC3545]:

"5.4 Packet Reordering

   ...Although CRTP is
   viewed as having risks for a number PW environments due to reordering
   and loss, it is still the protocol of choice in many cases.  CRTP was
   designed for reliable point to point links with short delays.  It
does
   not perform well over links with high rate of packet loss, packet
   reordering and long delays.  In such cases ECRTP [RFC3545] may be
   considered to increase robustness to both packet loss and misordering
   between the compressor and the decompressor.  This is achieved by
   repeating updates and sending of absolute (uncompressed) values in
   addition to delta values for selected context parameters. IPHC should
   use ..."

Thanks again,
Regards,
Jerry

> 
> Again, thanks for a quick followup, while I can still 
> remember what I was 
> thinking when I wrote the review :-)
> 
> Spencer 
> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art