jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-mops-streaming-opcons

Commentary: … cy streaming ) 
 This reads nicely to me . I 'm not asking about this for today ( it 's I - D cutoff day , after all ) , but is there any reference that could be provided for the user to learn more ? 
 Not really , I think I just know a guy who knows a guy who says this happened or something ... 
 From Will - 3 Caching Systems May be worth mentioning that concurrent gaming downloads nowadays drive larger traffic peaks than live or  streams . Additionally , something missing from this section is the impact of chunk transfer of aggregating responses . These are being used increasingly for low latency delivery . The caching system is receiving the object in real - time while simultaneously forwarding it to the client . The object size is not known until the transmission is complete . Much of caching infrastructure failover and redundancy is predicated on knowing the size of the object you are transmitting . Distribution tiers have a hard time separating a gap in data from a failure of an upstream component . Setting appropriate time - outs becomes problematic . 
 This is a true and fine point , but I 'm not sure it needs mention in a video - centric doc , except maybe how this impacts video delivery from the shared resources , but I think the congestion control sort of takes that . I 'll give it some thought , but I do n't think it 's really specific to caching or what we get out of raising it here , so I 'm leaning toward not doing anything in this section on this point . 
 I 'll follow up with a separate question about the other half of this comment , I 'm not quite sure what it 's saying . But it 's a good point that talking about some non - intuitive failure modes might be handy here . 
 Hi , - any update here ? 
 Not yet . I did send a message hoping to learn enough about the failure modes and what you can do about them to write something meaningful here , but there are some vacation - related delays and once people are back I may have to ping again .
Paragraph (version B):
And as with other parts of the ecosystem, new technology brings new
challenges.  For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not
yet know the size of the object.  Some of the popular caching systems
were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects that are being stored,
so the change in design requirements in long-established systems
caused some errors in production.  Incidents occurred where a
transmission error in the connection from the upstream source to the
cache could result in the cache holding a truncated segment and
transmitting it to the end user's device.  In this case, players
rendering the stream often had the video freeze until the player was
reset.  In some cases the truncated object was even cached that way
and served later to other players as well, causing continued stalls
at the same spot in the video for all players playing the segment
delivered from that cache node.
Draft: draft-ietf-mops-streaming-opcons

Commentary: Remove this material from Sec 5 : This section includes some material on UDP and TCP that may be tutorial for some readers . We can decide how to explain that , if the working group feels that this tutorial material is worth keeping . Spencer thought it was worth including , because it provides a contrast to the material on QUIC , which is significantly less tutorial , unless the reader participated in the QUIC working group .
Paragraph (version A):
This section includes some material on UDP and TCP that may be
tutorial for some readers.  We can decide how to explain that, if the
working group feels that this tutorial material is worth keeping.
Spencer thought it was worth including, because it provides a
contrast to the material on QUIC, which is significantly less
tutorial, unless the reader participated in the QUIC working group.
Draft: draft-ietf-mops-streaming-opcons

Commentary: We 've been getting help from people , but the ACKs section has n't changed much since -03 was submitted in November 2020 . 
 I found like two names that we had missed , and them to the ACKs section . I think we can merge this any time .
Paragraph (version A):
Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle
Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard,
and Mike English for their very helpful reviews and comments.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen,
Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock,
Mike English, Roni Even, and Will Law for very helpful suggestions,
reviews and comments.
Draft: draft-ietf-mops-streaming-opcons

Commentary: Just removing the ECN stuff .
Paragraph (version A):
Although Explicit Congestion Notification (ECN) has not been widely
deployed, Active Queue Management (AQM) systems such as PIE (RFC8033,
RFC8034), CoDel (RFC8289, RFC8290), or variants of RED RFC7567 that
would ordinarily induce early random loss under congestion by
discarding packets, and since the bytes contained in the delivered
packet are still available to the application, ECN usage can mitigate
head-of-line blocking where it is available.
Paragraph (version A):
"Classic" ECN, as defined in RFC3168, provides a congestion signal to
induce a sending rate backoff in flows that use Explicit Congestion
Notification-capable transport.  This backoff is similar to sender
behavior when packets are lost, but since packets are marked with a
congestion indicator instead of being discarded, the bytes contained
in these packets are still delivered to receivers, and this avoids
head-of-line blocking effects caused by potential congestion unless
packets are actually lost.
Paragraph (version A):
An experimental ECN mechanism, "low-latency, low-loss, scalable
throughput (L4S)", still being specified, would allow more gradual
changes in sending rates for L4S-capable transports when they are
available.  Although L4S doesn't have an immediate effect on head-of-
line blocking beyond Classic ECN, since marked packets are not lost,
the expectation is that L4S-capable senders responding to L4S ECN
signals would be less likely to experience a Classic ECN "Congestion
Experienced (CE)" signal that is interpreted as packet loss, or even
overrun available buffer space and cause actual packet loss.  These
more gradual responses are also expected to reduce jitter as measured
at the application layer, so that streaming senders can respond more
accurately to actual conditions on the path to the receiver.  I-
D.ietf-tsvwg-l4sops provides an operator's view of L4S and its impact
on existing ECN deployments.
Draft: draft-ietf-mops-streaming-opcons

Commentary: Also clarified relationship with UDP Behaviors section 
 I think this is ready to merge . Opinions ? 
 I was more concerned about overlap when I opened , but what 's in the section on Unreliable Transport and what 's in the section on UDP behaviors seems to read pretty well to me . Opinions ? 
 SRT , TS - Multicast over UDP , etc . 
 I THINK this is requesting a change in the " Unreliable Transport " section . 
 I think this one is also ready to close . Opinions ?
Paragraph (version A):
In contrast to segmented delivery, several applications use UDP or
unreliable SCTP to deliver RTP or raw TS-formatted video.
Paragraph (version B):
In contrast to segmented delivery, several applications use
unreliable UDP or SCTP with its "partial reliability" extension
RFC3758 to deliver Media encapsulated in RTP RFC3550 or raw MPEG
Transport Stream ("MPEG-TS")-formatted video MPEG-TS, when the media
is being delivered in situations such as broadcast and live
streaming, that better tolerate occasional packet loss without
retransmission.
Paragraph (version A):
Congestion avoidance strategies for this kind of deployment vary
widely in practice, ranging from some streams that are entirely
unresponsive to using feedback signaling to change encoder settings
(as in RFC5762), or to use fewer enhancement layers (as in RFC6190),
to proprietary methods for detecting quality of experience issues and
cutting off video.
Paragraph (version B):
The Secure Reliable Transport protocol SRT also uses UDP in an effort
to achieve lower latency for streaming media, although it adds
reliability at the application layer.
Paragraph (version B):
Congestion avoidance strategies for deployments using unreliable
transport protocols vary widely in practice, ranging from being
entirely unresponsive to congestion, to using feedback signaling to
change encoder settings (as in RFC5762), to using fewer enhancement
layers (as in RFC6190), to using proprietary methods to detect
"quality of experience" issues and turn off video in order to allow
less bandwidth-intensive media such as audio to be delivered.
Paragraph (version B):
More details about congestion avoidance strategies used with
unreliable transport protocols are included in udp-behavior.
Paragraph (version B):
This section includes some material on UDP and TCP that may be
tutorial for some readers.  We can decide how to explain that, if the
working group feels that this tutorial material is worth keeping.
Spencer thought it was worth including, because it provides a
contrast to the material on QUIC, which is significantly less
tutorial, unless the reader participated in the QUIC working group.
Draft: draft-ietf-mops-streaming-opcons

Commentary: … nd update public discussion venues 
 I left the previous description of    presentation , but removed the sub - references in that description ( which included the problematic ATT reference ) . 
 We should try to improve this reference - it 's a long page , additions are at the top , so we have to either scroll for a long time or search for the date to get the relevant part of the page . Maybe reach out to ATT to get fragment tags that work ?
Paragraph (version A):
Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to
March 30 Comcast,
Paragraph (version A):
Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19) Verizon.
Paragraph (version B):
Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to
March 30,
Paragraph (version B):
Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19)}.
Paragraph (version B):
Subsequently, the Inernet Architecture Board (IAB) held a COVID-19
Network Impacts Workshop IABcovid in November 2020.  Given a larger
number of reports and more time to reflect, the following
observations from the draft workshop report are worth considering.
Paragraph (version B):
Participants describing different types of networks reported
different kinds of impacts, but all types of networks saw impacts.
Paragraph (version B):
Mobile networks saw traffic reductions and residential networks
saw significant increases.
Paragraph (version B):
Reported traffic increases from ISPs and IXPs over just a few
weeks were as big as the traffic growth over the course of a
typical year, representing a 15-20% surge in growth to land at a
new normal that was much higher than anticipated.
Paragraph (version B):
At DE-CIX Frankfurt, the world's largest Internet Exchange Point
in terms of data throughput, the year 2020 has seen the largest
increase in peak traffic within a single year since the IXP was
founded in 1995.
Paragraph (version B):
The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and
children at school.  One might expect that the peak would have had
more impact on networks if it had happened during typical evening
peak hours for video streaming applications.
Paragraph (version B):
The increase in daytime bandwidth consumption reflected both
significant increases in "essential" applications such as
videoconferencing and VPNs, and entertainment applications as
people watched videos or played games.
Paragraph (version B):
At the IXP-level, it was observed that port utilization increased.
This phenomenon is mostly explained by a higher traffic demand
from residential users.
Draft: draft-ietf-mops-streaming-opcons

Commentary: This is based on the post - IETF 107 MOPS meeting where we talked about this . I chased some more references . 
 We should try to improve this reference - it 's a long page , additions are at the top , so we have to either scroll for a long time or search for the date to get the relevant part of the page . Maybe reach out to ATT to get fragment tags that work ?
Paragraph (version B):
The causes of unpredictable usage described in sec-unpredictable were
more or less the result of human choices, but we were reminded during
a post-IETF 107 meeting that humans are not always in control, and
forces of nature can cause enormous fluctuations in traffic patterns.
Paragraph (version B):
In his talk, Sanjay Mishra Mishra reported that after the CoViD-19
pandemic broke out in early 2020,
Paragraph (version B):
Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to
March 30 Comcast,
Paragraph (version B):
Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19) Verizon.
Paragraph (version B):
Weekday peak traffic increases over 45%-50% from pre-lockdown
levels,
Draft: draft-ietf-mops-streaming-opcons

Commentary: I think this is good to go .
Paragraph (version B):
Contributions are solicited regarding issues and considerations that
have an impact on media streaming operations.
Paragraph (version B):
Contributions can be emailed to mops@ietf.org, submitted as issues to
the issue tracker of the repository in venue, or emailed to the
document authors at draft-ietf-mops-streaming-opcons@ietf.org.
Paragraph (version B):
an overview of the issue's known prevalence in practice.  pointers
to write-ups of high-profile incidents are a plus.
Paragraph (version B):
an overview of the tradeoffs involved-how and why it's
helpful, what it costs.
Draft: draft-ietf-mops-streaming-opcons

Commentary: I actually used the URL in the draft to clone a copy , so I think this is good to go .
Paragraph (version A):
This document is in the Github repository at
https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are
welcome to open issues and send pull requests for this document.
Paragraph (version B):
Readers are welcome to open issues and send pull requests for this
document.
Draft: draft-ietf-mops-streaming-opcons

Commentary: This is my attempt at the changes we discussed in to include both the high - end and the typical bitrate needs . 
 Changes look good to me .
Paragraph (version A):
Height and width are in pixels, and frame rate is in frames per
second.  The actual bitrate required for a specific video will also
depend on the codec used, fidelity desired and some other
characteristics of the video itself, such as the amount and frequency
of high-detail motion, which may influence the compressability of the
content, but this equation provides a rough estimate.
Paragraph (version B):
Height and width are in pixels, frame rate is in frames per second,
and the motion factor is a value that ranges from 20 for a low-motion
talking heads video to 7 for sports, and content with a lot of screen
changes.
Paragraph (version B):
The motion factor captures the variability in bitrate due to the
amount and frequency of high-detail motion, which generally
influences the compressability of the content.
Paragraph (version B):
The exact bitrate required for a particular video also depends on a
number of specifics about the codec used and how the codec-specific
tuning parameters are matched to the content, but this equation
provides a rough estimate that approximates the usual bitrate
characteristics using the most common codecs and settings for
production traffic.
Paragraph (version A):
The bitrate requirements in scaling are per end-user actively
consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the
bandwidth requirements for a router on the delivery path with that
number of users downstream.  For example, at a node with 10,000
downstream users simultaneously consuming video streams,
approximately up to 80 Gbps would be necessary in order for all of
them to get 1080p resolution at 60 fps.
Paragraph (version B):
The bitrate requirements in scaling are per end-user actively
consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the
bandwidth requirements for a router on the delivery path with that
number of users downstream.  For example, at a node with 10,000
downstream users simultaneously consuming video streams,
approximately 80 Gbps would be necessary in order for all of them to
get typical content at 1080p resolution at 60 fps, or up to 180 Gbps
to get sustained high-motion content such as sports, while
maintaining the same resolution.
Draft: draft-ietf-mops-streaming-opcons

Commentary: consolidated venue and history sections , moved TBDs to issues list and removed from draft , a few links to help reviewers Any changes anyone would like to see , or does this work ? I propose that any of us other than the pull - requester should feel free to merge it if they 're happy with it and nobody has objected in a reasonably short time , or of course to suggest improvements .
Paragraph (version A):
TBD: suggestion from mic at IETF 106 (Dave Oran + Glenn Deen
responding): pre-placement for many use cases is useful-distinguish
between live vs.  cacheable.  "People assume high-demand == live, but
not always true" with popular netflix example.
Paragraph (version B):
Note to RFC Editor: Please remove this section and its subsections
before publication.
Paragraph (version B):
This section is to provide references to make it easier to review the
development and discussion on the draft so far.
Draft: draft-jholland-mops-taxonomy

Commentary: Add sections for constribution / discussion venues and for acknowledgements
Paragraph (version B):
This document is in the Github repository at
https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are
welcome to open issues and send pull requests for this document.
Paragraph (version B):
Substantial discussion of this document should take place on the MOPS
working group mailing list (mops@ietf.org).