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:spencer(_at_)mcsr-labs(_dot_)org]
Sent: Wednesday, February 07, 2007 12:20 PM
To: avt-chairs(_at_)tools(_dot_)ietf(_dot_)org;
pwe3-chairs(_at_)tools(_dot_)ietf(_dot_)org;
Andy(_dot_)Malis(_at_)tellabs(_dot_)com; HAND, JAMES, ATTLABS; ASH, GERALD R
(JERRY), ATTLABS; Mark Townsley; ext Cullen Jennings
Cc: ietf(_at_)ietf(_dot_)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 on exchanges with Luca Martini icw RFC 4446. The
registry is specified in RFC 4446
http://www.ietf.org/rfc/rfc4446.txt?number=4446. Using the text you
suggested in the email exchange with Andy:
"IANA has set aside the following PW type values for assignment
according to the registry specified in RFC 4446, Section 3.2:
PW type Description Reference
=============================================================
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]"
The PW control word enables distinguishing between various packets
types (e.g., uncompressed, UDP compressed, RTP compressed,
context-state, etc.). However, the PW control word indications are
not unique across HC schemes, and therefore the PW type
value allows
the HC scheme to be identified.
5.2 Header Compression Scheme Setup, Negotiation, & Signaling
Pseudowire Interface Parameter Sub-TLV type values are specified in
[RFC4446]. Two code-points have been reserved, as follows:
Parameter ID Length Description
References
0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544
configuration
Spencer: Again, something like "IANA is requested to assign these new
code-points" would help me with what seems to be ambiguous text.
Again, suggest this clarifying text:
"IANA has set aside the following Pseudowire Interface Parameter Sub-TLV
type values according to the registry specified in RFC 4446, Section
3.3:
Parameter ID Length Description References
0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544
configuration"
5.2.1 Configuration Option Format [RFC3544]
Both the network control protocol for IPv4, IPCP [RFC1332] and the
IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC
parameters
for their respective protocols. The format of the configuration
Spencer (Nit): I understand what you're saying with "their respective
protocols", but I don't think what you're saying, and what
I'm hearing, is
actually what these words mean. Perhaps "their respective controlled
protocols"? That would be unambiguous.
Agree with your proposed rewording.
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.
5.2.3 Enhanced RTP-Compression Suboption [RFC3544]
To use the enhanced RTP HC defined in [RFC3545], a
new sub-option 2 is added. Sub-option 2 is negotiated instead of,
not in addition to, sub-option 1. This suboption MUST be included
Spencer: is it obvious what the decompressor does if it sees
a compressor specifying sub-option 1 AND sub-option 2?
"Sub-option 1" refers to the RTP-Compression Suboption, as specified in
Section 5.2.2, and "sub-option 2" refers to the Enhanced RTP-Compression
Suboption, as specified in Section 5.2.3. These suboptions do not occur
together. I agree that this should be clarified in the text.
for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.
MAX_HEADER
NOTE: The four ROHC profiles defined in RFC 3095 do not provide
for a MAX_HEADER parameter. The parameter MAX_HEADER defined by
this document is therefore without consequence in these
profiles. Other profiles (e.g., ones based on RFC 2507) can
make
use of the parameter by explicitly referencing it.
Spencer: is there any statement you can make about the
largest header that
can be compressed in these profiles? Even if not, it might be
good to say so
explicitly - I don't know what "without consequence" says about what
implementations may encounter in practice.
Have to look into whether there is largest header that can be compressed
in these ROHC profiles. I agree that the 'without consequence' phrasing
should be clarified.
5.4 Packet Reordering
Packet reordering for ROHC is discussed in [RFC4224], which is a
useful source of information. In case of lossy links and other
reasons for reordering, implementation adaptations are needed to
allow all the schemes to be used in this case. Although CRTP is
viewed as having risks for a number PW environments due to
reordering
Spencer (Nit): "a number of PW environments" ("of" is missing)
OK.
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).
6. HC Pseudowire Setup Example
The Label Mapping message sent from R4/HD to R1/HC would be almost
identical to the one sent in the opposite direction, with the
following exceptions
Spencer (Nit): missing a colon here...
OK.
As soon as either R1/HC or R4/HD had both transmitted and received
Label Mapping Messages with the same PW Type and PW ID, it could
Spencer: "it" is not entirely clear here. "It" usually refers
to one thing
(in my mind), and the subject of the sentence is two things
("either R1/HC
or R4/HD"). Mumble. Would it help to say that each ROHC
endpoint considers
the PW established when it has seen both packets?
Agree with your suggested rewording.
consider the PW established. R1/HC could send ECRTP packets using
the label it received in the Label Mapping Message from R4/HD, Lr4,
and could identify received ECRTP packets by the label it
had sent to
R4/HD, Lr1. And vice versa.
The following 3 RTP packets from this flow would be sent as
Spencer: "following" is not entirely clear here. Suggest "next"?
OK.
COMPRESSED_UDP_8, to establish the absolute and delta values of the
IPv4 identifier and RTP timestamp fields. These packets would use
the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS
and PW headers at the beginning of these packets would be formatted
as follows:
--- Begin Message ---
Hi,
In a bit of off-list discussion, we had two threads:
1. would it be practical to assume that the RFC 3544
protocol would be present for IPHC/CRTP eCRTP? The answer
is that the implementations are not restricting themselves
to that design, so Kristofer Sandlun's thoughtful codepoint
suggestion isn't an option.
2. are there some very pressing reasons why vendors cannot
use eCRTP and find themselves using CRTP? The answer to
this turns out to be yes, and turns out to be
sometimes IPR, which is certainly not an unknown finding
for IETF...
I agreed to put cRTP back in the registrations with a note
that reflects that the use of cRTP has to be an informed tradeoff
(because the later IETF documents say that cRTP has risks for
general use). I've cc'd the AVT chairs because they may want
to take the new protocol takeup info into account. Of course,
no specifics - that's also not unknown for IETF.
Here's Yet Another List of these - maybe we are looking at our last one
:)
------
0x001A ROHC Transport Header-compressed Packets [RFC3095,
draft-ietf-rohc-over-reordering-03.txt]
0x001B eCRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D cRTP Transport Header-compressed Packets
[RFC2508][Note 1]
[Note 1] Although CRTP is viewed as having risks for a number
PW environments due to misordering and loss, it is registered
because of markets where commercial issues lead to its choice
In these circumstances, it must be implemented and deployed
with care.
-- Add Informational Reference to draft-ietf-rohc-over-reordering-03.txt
------
I added the i-d that gives the advice about improving ROHC for
reordering to the references for ROHC. This was a good idea derived
from Kristopher's email.
I couldn't decide there was urgency to record Kristofer's additional
guidance
IPHC and eCRTP here. But his expertise on these convinced me that IPHC
can
be there without causing trouble,
So I hope this is it for this material.
Now, about part 1 of my Discuss, if Luca or the group will respond, I'd
love to settle this.
Allison
_______________________________________________
pwe3 mailing list
pwe3(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/pwe3
--- End Message ---
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf