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 uploaded
Regards
Christian
> 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 reference
> With 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 comment
> At 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 order
OLD
It 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.
NEW
It 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 scope
BEFORE
The 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.
AFTER
The 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@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
