RE: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi Spencer, Thanks a lot for the quick reply. Please see below. -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 12:52 AM To: ASH, GERALD R (JERRY), ATTLABS Cc: ietf@ietf.org; General Area Review Team; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; HAND, JAMES, ATTLABS; Mark Townsley; ext Cullen Jennings; GOODE, B (BUR), ATTLABS; raymond.zhang; [EMAIL PROTECTED] 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi Spencer, Many thanks for your thorough and constructive review of the draft. Please see responses to your comments below, and please let us know of any further comments or suggestions. Thanks, Regards, Jerry -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 12:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; HAND, JAMES, ATTLABS; ASH, GERALD R (JERRY), ATTLABS; Mark Townsley; ext Cullen Jennings Cc: ietf@ietf.org; General Area Review Team Subject: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-hc-over-mpls-protocol-07 Reviewer: Spencer Dawkins Review Date: 2007-01-30 IETF LC End Date: 2007-07-07 IESG Telechat date: (not known) Summary: This document is on the right track for publication as Proposed Standard. I had some questions (please see below), but the quality seemed very good (thanks for that). I'd like to see some work on my comments in 5.1, 5.2 (especially 5.2.1), and 5.3. I had some comments on clarity in section 6, but these were more-than-nits-but-not-problems. Thanks! Spencer Comments: 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. The interest in header compression (HC) is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095], and also to increase scalability of HC. MPLS is used to route HC packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. Goals and requirements for HC over MPLS are discussed in [RFC4247]. The solution put forth in this document using MPLS pseudowire (PW) technology has been designed to address these goals and requirements. Spencer (Nit): I think the last sentence is actually The solution using MPLS pseudowire (PW) technology put forth in this document has been designed to address these goals and requirements. (the solution wasn't actually put forth using MPLS PW technology :-) Agree with your suggested rewording. 2. Contributors Besides the editors listed in Section 12, the following people contributed to the document: Spencer (Nit): I like the use of this section, but it seems odd to have it so far from the acknowledgements section. I'm not sure if IESG has an agreed sense of taste for placement or not. Cullen? In a recent RFC review I saw the RFC editor put the Contributing Authors section right before the Editor's Address section, where both sections were toward the end of the RFC (near the Acknowledgements section). It seems like a good approach IMO. 3. Terminology PSN Tunnel Signaling: Used to set up, maintain, and tear down the underlying PSN tunnel Spencer (Nit): s/Used/A protocol used/ (all of the other definitions look like complete sentences, this one is a fragment) OK. 5.1 MPLS Pseudowire Setup Signaling This specification defines new PW type values to be carried within the FEC object to identify HC PWs for each HC scheme. The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and MUST be used to indicate the HC scheme being used on the PW. The following PW type values have been set aside for assignment by IANA: 0x001A ROHC Transport Header-compressed Packets[RFC3095] 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001C IPHC Transport Header-compressed Packets[RFC2507] 0x001D cRTP Transport Header-compressed Packets[RFC2508] Spencer: have been set aside for assignment by IANA, with RFC references, confused me badly here. I read this text as saying that these values were set aside IN [RFC3095], etc, which was wrong. Perhaps IANA is requested to assign the following new PW type values:? The language is based
