Minutes IETF101: panrg
minutes-101-panrg-00

—

# Service Aware Networking using SR, presented by D. Bernier

    Brian Trammell (chair hat off): 
        Data plane is clear. Control plane — how do you get path properties
         to the edge — is the focus?
        
        Putting path property at the ends is easy, there are many ways, e.g., 
        path signaling. Main challenge: how does one know customer wants a 
        particular property? How can this be automated? 

    Rüdiger Volk: Is point about how to make the network application aware?
        
        Service-awareness does not mean that application awareness. 
        Challenge in the beginning is ability to configure quickly without overhead.

 

# Path Awareness with Socket Intents, presented by T. Enghardt

    Richard: How much granularity are you willing to allow? 
    Different paths may have different policies. Are you planning on 
    integrating this into the API?

        Not yet, there’s more room for collecting path information. 
        Are there middleboxes, is anything blocked, etc? We’re blocked by 
        the socket API.

    Richard: Flow dynamics change over time and may be different from 
    the start of a connection. Bandwidth may change as a function of 
    different bottlenecks. (Taken offline.)

    Lee Howard: How does per-prefix (and address family) latency interact
    with or Happy Eyeballs? Do you do your own socket setup instead of 
    what’s in the OS?

        We don’t use HE — just POSIX sockets.
    
    Olivier Tilmans: How would handle the situation when dealing with a 
    middlebox or proxy?
    
        We can differentiate SRTT per endpoint and then hope not every flow 
        is subject to the proxy or middle box. But of course this scenario 
        makes it harder to get an accurate path RTT estimate.
    
    Fabian Schneider: Connection receiver does not know intent of the 
    receiver. Have you looked at ways to send intents to the peer?

        Intents are meant to be local policies. Applications must use the API 
        to utilize intents. Not exchanged. Application interaction could 
        convey intents to the other side, and peers could respond to 
        application behavior accordingly.

# FAST, presented by T. Herbert

    DKG: What happens if both providers have the same scheme?

        Tickets may be used bidirectionally — two tickets per packet, 
        where one is local and the other, reflected. 

    Aaron Falk: What happens if the number of packets flowing in one direction
     does not match that in the other direction? What do you do with the 
     excess tickets?

        Each packet may have a (per-flow) ticket — sort of as a flow 
        identifier. 

    Fabian Schneider: Why did you not explore multiple tickets, where some are
    scoped to specific networks?

        We thought about using AS numbers to associate with a ticket, but stuck
        with at most two (one for each direction). 

    Fabian Schneider: You might still want each network to have a ticket agent 
    that assigns tickets to local processing, but that’s not possible with one 
    ticket per direction. 

        You get tickets from local network. If you want more elaborate 
        schemes, you need to contact other agents in other networks. You can 
        schedule an entire path if you use segment routing, for example.

    Fabian Schneider: How large do you want the tickets to be?

        As small as possible, but deferred for now.

    Uma (Huawei): How do intermediate nodes verify destination options? 
    Does this not need to be a hop-by-hop option? 

        An interesting story. Hop-by-hop options are more likely to be 
        dropped. 

    Uma: Why wasting extra space for this option? Why not use the ILA?

        Number of bits available there is small. If it’s possible, 
        that’d be great.

    Alan Chelek: Is there any way you imagine the network attaching 
    something that says it obeyed the ticket? Or is there a way to communicate
    ticket expiration?

        We’ve not really specified many characteristics of tickets. You 
        probably could do this, though it would impact the application-facing 
        API. It’s not clear how dynamic this process would be — should one be 
        able to rotate tickets every N minutes? 

    Alan Chelek: There may be cases where you want the network to state that 
    it's honoring the ticket, since you may rely on it.

    Richard : How do you prevent people from hijacking tickets? How do you 
    bind them to packets? Do you really need tickets if there’s another way 
    to bind them to packets?

        Binding (e.g. to a 4 tuple) would be stateful, but we’d like to avoid 
        that since it’s stateful. We want to avoid stateful tracking. 

    Richard: You’re matching the matching part in the ticket?

        If we want to restrict tickets to a 4 tuple, we may hash the 4 tuple 
        and include it in the ticket.

    Ruediger Volk: Not optimistic about getting support for long header chains
    for any reason. You seem to be taking care of stuff that happens in the
    originator’s domain. As you pass that boundary, things are forward
    transparently. A clear statement about what kind of service could be 
    controlled this way is needed. Do we need more negotiation if we want to 
    extend beyond this boundary?

        The only entity the application talks to is the local network. 
        Application only needs to know that a packet “belongs to” a path. If 
        there is to be negotiation, that would need to be done by the 
        initiator to each of the successor networks. However, maybe the 
        ticket already has meaning to other networks that the application 
        is unaware of. 

    DKG: Network provider may not want to deliver voice traffic to the user. 
    Can users protect themselves against adversarial networks that use tickets 
    for malicious purposes.

        Users need to trust the network. If users request service A and that’s
        not available, then there’s nothing to be done. Application would
        need to decide it’s getting the service it paid for. 

    Frank Brockners: It would be nice if the application did not have to 
    request every individual ticket. It could become costly to request one each 
    for each packet. Is there a way to allow the application to generate 
    identifiers so it doesn’t have to talk to the agent each time.

    Frank: Have you looked at other encapsulations beyond V6 and destination 
    options? What about V4 or MPLS?

        Those could be leveraged.

    Brian Trammell: How big are these tickets?
        
        Goal: 16B

    DKG: Have you looked at DLEQ proofs from yesterday’s CFRG?

        Not yet — may consider.
    
    Chris Wood: Those proofs can be batched, too, which may be good for performance.


# TAPS Architecture and Interface, presented by T. Pauly


    Toerless Eckert: Which draft is the best to read with regards to ICE experience?

        Probably the architecture document, though the API one may also help.

    Colin Perkins: Architecture and interface will help, and the implementation 
    draft has much longer advice.

        Yes — these are all 00 and will be flushed out further.

    Colin Perkins: The idea is to incorporate the ICE and Happy Eyeballs algorithms.

    Aaron Falk: This is compatible with the socket intents work discussed earlier.

# Bad Ideas in Transport Signaling, presented by S. Dawkins

    Toerless Eckert: We can make pigs fly provided there is 
    business behind it. Simplicity and architecture are not the 
    only reasons to sell things in the IETF. Providing more details 
    there would help.

        See section 4.5.

    Gorry: Useful to show people with new proposals who are reinventing 
    work or doing things that failed. There are many BOFs like this.

    Aaron Falk: IETF does not have monopoly on bad ideas. TCP over satellite 
    was created to inform the satellite industry to inform them what *not* 
    to do. People often forget that not all problems are global — the Internet
    is different in many different places.


# Next Steps

    Allison Mankin: hum for creating the RG. 
    [strong hum in support of approving the RG]

    Spencer Dawkins: Take is that this work will happen in the IRTF or 
    continues to happen in the IETF elsewhere. 

    Toerless Eckert: What is the scope of the research? Perhaps someone 
    should summarize aspects such as privacy that we need to address.

    Brian Trammell: Send a message to the list or a PR to the questions 
    draft regarding new work.

    Toerless Eckert: Interested in getting applications better paths, 
    not necessarily 1 vs N paths.

    Lee Howard: Questions draft is important and will help drive charter. 
    May want to suggest rephrasing some bits and cite some omitted references.

    Rüdiger Volk: Is the term “path aware” misleading? Main question asking 
    is “what is the path?”, though that’s not needed at all layers. Perhaps 
    the crucial question is how we communicate and use available services? 
    If you invent a rich repertoire or taxonomy of services that may be used 
    by lambdas in the transport, that would lead to better use for the output 
    of the group. 

    Spencer Dawkins: Please look at RFC 7418 to learn what’s different 
    between the IRTF and IETF.

    Toerless Eckert: It would be good to have a self-classification for each 
    draft that describes where it fits into the spectrum. 

    Matt Mathis: Very cool ideas in this space. There are also cool ideas 
    that were not deployed. One valuable thing this RG can do is bridging 
    between good ideas and efforts in the past that had not been deployed. 
    Helping people understand barriers to deployment would be useful. 
    Summarizing comment: the Internet is different everywhere.

    Jake Holland: Consider adding “what to do” to the companion draft. 
    
    Spencer Dawkins: There’s another draft for that.