Re: [Stackevo] My notes on https://tools.ietf.org/html/draft-iab-marnew-report-00

["Brian Trammell (IETF)" <[e-mail]>]

hi Spencer,



> On 4 Sep 2017, at 02:26, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Dear StackEvo,
> 
> Brian has Natasha and I down to provide an updated Marnew report for discussion on this week's call.
> 
> I went through https://tools.ietf.org/html/draft-iab-marnew-report-00, and had a bunch of comments (below), but the vast majority are nits. The biggest changes I proposed were putting paragraphs in Section 7 and Section 8 that said basically "this is what we thought immediately after the workshop", and that's the outstanding comment I remember when we last worked on this draft.
> 
> The high-order bit on this is that Natasha and the people who commented have this draft in pretty good shape now. I have better understanding of the bar for IETF stream docs than for IAB docs, but that's the way it looks to me.
> 
> So, I should also ask - this version is just a name change from https://tools.ietf.org/html/draft-nrooney-marnew-report-03, and -03 and -02 were only date changes to prevent expiry. Has the IAB, or anyone else, provided comments since April 4, 2016, when -01 (which contained lots of changes) was submitted? I likely wouldn't have seen them.

IIRC (the Mailman archives are empty, and my other old archived mail is stored offline at the moment, so if someone recalls this message and can find it I'd appreciate it), the IAB received comments from Stephen Farrell amounting largely to "this document is too neutral about certain operational practices", which IMO kind of misses the point of a workshop report to report on the discussion at a workshop. I don't recall any other input.

The only additional comment from the Prague stackevo meeting was "correct tense in Next Steps, and remove items overtaken by events" -- the document should report what happened, but it should be current.

Cheers,

Brian

> Thanks,
> 
> Spencer
> 
> --
> 
> Nit: in section 2.1.1, "We should not delve into:" shouldn't be an entry in this list - it should be unbulleted, so it introduces the following bullets.
> 
> Nit: this text
> 
>   From a recent study [Pew2014] 64% of users said concerns over privacy
>    have increased, 67% of mobile internet users would like to do more to
>    protect their privacy.
> 
> would be better as "have increased, and 67%"
> 
> Nit: 'further inforcing the "user first" principle' should be "enforcing"
> 
> I don't know what "Users also have certain security expectations from particular contexts" means - specifically, it seems like I should have security expectations from particular contexts, but I can't confirm that because I don't know what kinds of contexts we're talking about ("I need context").
> 
> I'm not sure what
> 
>   Technologies which can impact user privacy sometimes do this ignorant
>    of the privacy implications or incorrectly assume that the benefits
>    users gain from the new technology outweigh the loss of private
>    information.
> 
> means - part of the problem is that technologies themselves aren't ignorant of anything. Is
> 
>   Implementers sometimes develop technologies which can impact user privacy
>    sometimes do this while remaining ignorant
>    of the privacy implications of those technologies or incorrectly assuming
>    that the benefits that users gain from the new technologies outweigh the
>    loss of private information from that new technologies.
> 
> what's intended?
> 
> Nit: "absued" should be "abused"
> 
> In
> 
>  Some suggested solutions for network management of encrypted traffic
>    have suggested "trust models".
> 
> uses "suggested" as an adjective and a verb in the same sentence. Perhaps
> 
>  Some proposed solutions for network management of encrypted traffic
>    have suggested "trust models".
> 
> This text
> 
>    Understanding the extent of "auto click through" may
>    help make better decisions for consent requests in the future.
> 
> isn't clear about who needs to understand this (I believe "users" is implicit, but we should say who doesn't understand this now), and "the extent of" reads to me as "how much", and "what" is also important. Perhaps
> 
>    If users understand the implications of "auto click through" more clearly,
>    that understanding may help them make better decisions for consent requests
>    in the future.
> 
> In this text,
> 
>    Issues with this involve
>    trust only being applied on end.
> 
> I don't understand what "on end" means. Because I'm an IETF AD, I'd guess
> 
>    Issues with this involve
>    trust only being applied on endpoints.
> 
> but then I'm not sure what the sentence means. Is it
> 
>    Issues with this involve ensuring that
>    trust can only be applied on endpoints.
> 
> so that the issue is avoiding forged trust operations, or something else?
> 
> The second sentence in this text,
> 
>   o  Latency versus Bandwith: allowing the content provider to indicate
>       whether a better bandwidth or lower latency is of greater priority
>       and allowing the network to react.  Where this bit resides and how
>       to authenticate it would need to be decided.
> 
> might be clearer if the first sentence included the actual signaling mechanism the second sentence refers to, as
> 
>   o  Latency versus Bandwith: allowing the content provider to indicate
>       with a single bit whether a better bandwidth or lower latency is
>       of greater priority
>       and allowing the network to react.  Where this bit resides and how
>       to authenticate it would need to be decided.
> 
> I thought
> 
>   o  No network management tools: disabling all network management
>       tools from the network and allow the protocols to manage
>       congestion alone.
> 
> might be clearer if it was
> 
>   o  No network management tools: disabling all network management
>       tools from the network and relying on end-to-end protocols to manage
>       congestion.
> 
> This text
> 
>    Some workshop attendees agreed that applications
>    declaring was quality of service they require was not a good route
>    given the lack of success in the past.
> 
> wasn't easy to parse. Perhaps
> 
>   Some workshop attendees agreed that relying on applications to declare
>   the quality of service they require was not a good route, given the
>   lack of success with this technique in the past.
> 
> ?
> 
> In this text
> 
>    Some workshop attendees suggested
>    any exchange of information should be biodirectional,
> 
> should probably be
> 
>    Some workshop attendees suggested
>    any exchange of information should be bi-directional,
> 
> ("bio-" anything would tell the reader that whatever we're talking about is alive :-)
> 
> This text
> 
>    TCP was originally devised to work
>    on a specific network model that did not anticipate the high error
>    rates and highly variable available bandwidth scenarios experienced
>    on modern radio access networks.
> 
> would be more accurate if it was
> 
>    TCP was originally devised to work
>    on a specific network model that did not anticipate the high bandwidth,
>    high error
>    rates and highly variable available bandwidth scenarios experienced
>    on modern radio access networks.
> 
> This text had nits in a couple of places:
> 
>   Strongly related to content providers, CDNs are understood to be a
>    trusted deliver of content and have shown great success in fixed
>            deliverer
>    networks.  Now traffic is moving more to mobile networks there is a
>                  ^that
>    need to place caches at the edge of the network (e.g. in the Gi LAN
>                                                                 ^^^^^^
>    or the radio network) within the mobile network.  Places caches at
>                                                      Placing
>    the edge of the mobile network is a solution, but requires standards
>    developed by content providers and mobile network operators.  The
>    CNDi Working Group [CDNI] at IETF aims to allow global CDNs to
>    interoperate with mobile CDNs; but this causes huge trust issues for
>    the caching of encrypted data between these CDNs.  Some CDNs are
>    experimenting with "Keyless SSL" to enable safer storage of content
>    without passing private keys to the CDN.  Blind Caching is another
>    proposal aimed at caching encrypted content closer to the user and
>    managing the authentication at the original content provider servers.
> 
> Re: "Gi LAN" above - is that the right way to describe Gi these days? I thought (without re-reading 3GPP specs I last read more than a decade ago) Gi was (from Wikipedia) an "IP based interface between the GGSN and a public data network (PDN) either directly to the Internet or through a WAP gateway", which doesn't scream "LAN" to me, but I'd bet Natasha knows someone who could tell us, if no one on StackEvo has an opinion.
> 
> In this text,
> 
>   At the end of the session the panelists were asked to identify one
>    key collaborative work item, these were:
> 
> I'd suggest
> 
>   At the end of the session each panelist was asked to identify one
>    key collaborative work item. Their answers were:
> 
> I noticed Chatham House Rule mentioned without a reference at the beginning of Section 6, so checked to make sure there was a reference on first usage. There is, but the Section where that usage appears is "1.4.  Use of Note Well and Charter House Rule", and that should probably be "1.4.  Use of Note Well and Chatham House Rule", I guess?
> 
> In this text,
> 
>   Mobile networks are regulated, compliance is mandatory (and can
>    result in service license revocation in some nations round the world)
>    and can incur costs on the mobile network operator.  Regulation does
>    vary geographically.  Some regulations are court orders, others are
>    "block lists" of websites such as the Internet Watch Foundation list
>    [IWF].  Operators are not expected to decrypt sites, so those
>    identified sites which are encrypted will not be blocked.
> 
> the last sentence doesn't sound right to me. Was the point more like
> 
>    Operators are not expected to decrypt sites, so those
>    identified sites which are encrypted will not be blocked based on
>    content.
> 
> ? If so, I'd bet there are regulators who tell operators to block encrypted sites, at least some places on the Internet, but this is far from my expertise.
> 
> "restirctions" should be "restrictions".
> 
> In this text,
> 
>   These regulations do not always apply to the internet, and the
>    internet community is not always aware of their existance.
>                                                    existence
>    Collectively the internet community can work with GSMA and 3GPP and
>    act collectively to alleviate the risk imposed by encrypted traffic
>        collaboratively, or just drop one of the "collectively"s
>    for lawful intercept.  The suggestion from attendees was that if any
>    new technical solutions built should have the ability to be easily
>                           ^are
>    switched off.
> 
> Nit: "exhaustve" should be "exhaustive".
> 
> I think Section 7 is valuable to preserve, but the first paragraph needs to say "this was what we thought would happen immediately after the workshop, and hasn't been updated to reflect what's happened since then". If we do that, I'd be fine with leaving the bullets in place. To suggest text:
> 
> 7.  Requirements and Suggestions for Future Solutions
> 
>    Note to the reader:
>    Based on the invited talks and group discussions throughout the workshop,
>    attendees (*** who did actually put this together???***) collected a
>    set of requirements and possible solutions that would meet those
>    requirements. This list follows, but has not been updated to reflect what
>    has happened since the workshop was held, and is not exhaustive.
> 
>    Requirements
> 
>    (the current list of requirements follows)
> 
> In this text, I'd suggest
> 
>   o  Flexibility: radio access network qualities vary vastly and
>       different network needs in content can be identified, so any new
>                         ^ "needs for different content types can be identified"?
>       solution should be flexible to either the network type or content
>       type or both.
> 
> and, after the list of requirements, I'd suggest
> 
>      Note to the reader: A collection of solutions suggested throughout
>      was also created immediately after the workshop, and is given
>      below.  This list of solutions also hasn't been updated to
>      reflect what has happened since the workshop, and also isn't exhaustive.
> 
>      Solutions
> 
>      (the current list of solutions follows)
> 
> In this text,
> 
>   o  Evolving TCP or evolution on the transport layer: this could take
>       a number of forms and some of this work is already existing within
>       IETF.  Other suggestions include:
> 
>    o  Congestion Control: many attendees cited congestion control as a
>       key issue, further analysis, investigation and work could be done
>       here.
> 
>    o  SPROUT: research at MIT which is a transport protocol for
>       interactive applications that desire high throughput and low
>       delay.  [SPROUT]
> 
>    o  PCC: Performance-oriented Congestion Control: is a new
>       architecture that aims for consistent high performance even in
>       challenging scenarios.  PCC enpoints observe the connection
>                                   ^ endpoints
>       between their actions and their known performance, which allows
>       them to adapt their actions.  [PCC]
> 
> the second, third, and fourth bullets should be sub-bullets under the first bullet. Next on the list,
> 
>   o  CDNs and Caches: placing caches closer to the mobile user or
>       making more intelligent CDNs would result in faster content
>       delivery and less train on the network.  Related work includes:
> 
>    o  Blind Caching: a proposal for caching of encrypted content
>       [BLIND_CACHING].
> 
>    o  CDN improvements: including keyless SSL and better CDN placement.
> 
> should also be a bullet with two sub-bullets under it.
> 
> For
> 
>       The Base Station holds the
>       Radio Resource Controller and scheduler which could provide either
>       a place to host solutions or data from the Base Station could help
>       in devising new solutions.
> 
> I'd suggest
> 
>       The Base Station holds the
>       Radio Resource Controller and scheduler which could provide
>       a place to host solutions, or could provide data that would
>       help in devising new solutions that would be hosted elsewhere.
> 
> For
> 
>   o  Identify traffic types via 5-tuple: information from the 5-tuple
>       could provide understanding of the traffic type which network
>       management could then be applied.
> 
> I'd suggest
> 
>   o  Identify traffic types via 5-tuple: information from the 5-tuple
>       could provide understanding of the traffic type. Network management
>       could then be applied, based on that traffic type.
> 
> In this text,
> 
>  o  Metrics and metric standards: in order to evolve current protocols
>       to be best suited to today's networks data is needed on the
>       current network situations, protocol deployments, packet traces
>       and middlebox behaviour.  Futher than this proper testing and
>       debugging on networks could provide great insight for stack
>       evolution.
> 
> I'd suggest
> 
>  o  Metrics and metric standards: in order to evolve current protocols
>       to be best suited to today's networks, data is needed on the
>       current network situations, protocol deployments, packet traces
>       and middlebox behaviour.  Proper testing and
>       debugging on networks could provide great insight for stack
>       evolution.
> 
> For this text,
> 
>   o  5G: Mobile operator standards bodies are in the process of setting
>       the requirements for 5G, requirements for network management could
>       be added.
> 
> I'd suggest
> 
>   o  5G: Mobile operator standards bodies are in the process of setting
>       the requirements for 5G. Requirements for network management could
>       be included as part of that process.
> 
> For
> 
>   o  How to do congestion controlling in RAN.
>                           ^control
> 
> Section 8, "Next Steps", should probably also be put into context. I'd suggest starting it with
> 
>    Note to the reader:
>    Based on the invited talks and group discussions throughout the workshop,
>    attendees (*** again, who did actually put this together???***) collected a
>    set of proposed "Next Steps". This list follows, but has not been updated to reflect what
>    has happened since the workshop was held.
> 
>    Post-workshop Next Steps:
> 
> In addition, Section 8 is pretty dense. I'd suggest breaking the single paragraph up, something like this:
> 
>   The next steps for MaRNEW attendees are to begin work on a select
>    list of the above recommended solutions and other suggestions within
>    the IETF and within other organisations.  At IETF95 the ACCORD BoF
>    will be held which will bring the workshop discussion to the wider
>    IETF attendance and select key areas to progress on; these are likely
>    to be definitions of the metrics to be collected:
> 
>    - more information on the stack evolution ideas and their impact to network management,
>    - Mobile Throughput Guidance evolution,
>    - evolution of the Blind Caching work and draft definitions of the "1 bit for latency / bandwidth tradeoff" idea.
> 
>    As identified in the "Better Collaboration" section
>    together we need to ensure that both groups continue the positive
>    relationship to move these ideas forward into being real and workable
>    solutions and both groups need to understand that even though
>    collaboration between the operator network and the internet is of
>    great importance the item of most importance is the experience and
>    security for the users using these services.
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo