| Thanks for the updates! I think these are an improvement.
Best, Tommy On Nov 5, 2024, at 7:01 AM, Christian Schmutzer (cschmutz) <cschmutz=40cisco.com@xxxxxxxxxxxxxx> wrote:
Hi Tommy,Thank you for your review. Please see my comments inline via [cs]. Outlined changes with OLD/NEW are incorporated in the new -10 version I just uploadedRegardsChristian On 19.10.2024, at 01:04, Tommy Pauly via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Tommy Pauly
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
First, as a comment on readability: this document (even for an IETF document!)
has some particularly dense acronyms and terms! :) I appreciate the detailed
terminology section, but have a couple comments on possible improvements.
- In general, acronyms used before the terminology section are indeed written
out, which is great, but there are some missing like "CE" and "PE". Please
define such terms on first use!
[cs] We tried our best ;-) ... CE and PE are now also written out at first appearance.- Where possible, it would be useful to add RFC references for some of the terms
so more detailed definitions can be read. This might be useful on the applicable
entries in the terminology section.
[cs] good idea, I put RFC links at the end of each entry in the terminology section where I could find a suitable referenceWith regards to transport, much of this document is discussing a virtual layer
to represent non-packet-switched link, so many normal transport recommendations
might not apply. This is acknowledged by the document.
I think that section 8, "QoS and Congestion Control", could potentially
benefit from more up-to-date references and recommendations for how the
underlying packet-switched network can achieve the lowest loss and jitter.
The current text is pointing to RFC 2475 for diffserv and asking to reserve
a traffic-engineered path. I wonder if the layers that are detecting loss or
reordering (at the PLE encapsulation layer, from my understanding) could benefit
from marking like those used for L4S (RFC 9330).
[cs] I don’t think L4S can be applied to PLE traffic. For sure it can be applied to other traffic run in the same PSN, but I would consider that out of scope for this document. See also next commentAt the least, it would be good
to have a bit more discussion in this section about the overall impact of
loss or reordering on the underlying network, and what impact that does have
on the virtual link.
[cs] I have adjusted section 7.2.2 as follows to explain what has to happen when packets get out of orderOLDIt MAY use the sequence number in the RTP header for the same purposes.The payload of a lost packet MUST be replaced with equivalent amount of replacement data. NEWIt MAY use the sequence number in the RTP header for the same purposes. The CE-bound IWF MAY support re-ordering of packets received out of order. If the CE-bound IWF does not support re-ordering it MUST drop the misordered packets.The payload of a lost or dropped packet MUST be replaced with equivalent amount of replacement data. and I reworded section 8 to be more clear and define the scopeBEFOREThe PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS representing constant bit-rate (CBR) flows cannot respond to congestion in a TCP-friendly manner as described in {{?RFC2913}}.Hence the PSN providing connectivity for the PLE VPWS between PE devices MUST be Diffserv {{?RFC2475}} enabled and MUST provide a per domain behavior {{?RFC3086}} that guarantees low jitter and low loss.To achieve the desired per domain behavior PLE VPWS SHOULD be carried over traffic-engineered paths through the PSN with bandwidth reservation and admission control applied.AFTERThe PSN carrying PLE VPWS may be subject to congestion. Congestion considerations for PWs are described in {{Section 6.5 of RFC3985}}. PLE VPWS represent inelastic constant bit-rate (CBR) flows that cannot respond to congestion in a TCP-friendly manner as described in {{?RFC2914}} and are sensitive to jitter, packet loss and packets received out of order.The PSN providing connectivity between PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, but not exhaustively, are a Diffserv-enabled {{?RFC2475}} PSN with a per domain behavior {{?RFC3086}} supporting Expedited Forwarding {{?RFC3246}}. Traffic-engineered paths through the PSN with bandwidth reservation and admission control applied. Or capacity over-provisioning.Nit: I think "Physical Subcoding Layer (PCS)" is the wrong definition, it
should be the same as "PCS - Physical Coding Sublayer"
[cs] thanks, fixed
-- last-call mailing list -- last-call@xxxxxxxxTo unsubscribe send an email to last-call-leave@xxxxxxxx
|
