Minutes IETF102: tsvwg
minutes-102-tsvwg-01

IETF 102  Montreal July 15 - 20, 2018
Draft Agenda
WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote)
Note Takers: Tommy Pauly, Tom Jones

Session I: Thursday Jul-19-2018 1550

1. Chairs Update:
  RFCs completed:
        None

  Chairs update on:
     draft-ietf-tsvwg-iana-dscp-registry (RFC-Ed)
     draft-ietf-tsvwg-rfc4960-errata (IESG) - see later
     draft-ietf-tsvwg-fecframe-ext (Post WGLC)
     draft-ietf-tsvwg-rlc-fec-scheme (Post WGLC)
     draft-ietf-tsvwg-le-phb  (WGLC)

  Milestone updates and review of WG Progress:
    Feedback on draft-ietf-tsvwg-tunnel-congestion-feedback (Waiting for
    editors) Update on ecn-encap-guidelines and 6040update-shim (Waiting for
    WGLC)

Originally wanted ECN encapsulation drafts out for June 2018, but moving those
to Oct 2018. L4S drafts are aiming for September, but chairs think this may be
a bit optimistic and we want to push those out. Tunnel Congestion feedback will
likely be adjusted in the Bangkok meeting. Moving ahead and on schedule for all
other items in charter milestones.

2. Chairs: Announcements and Heads-Up

2.1 Chairs: Other Drafts Related to TSVWG
    draft-olteanu-intarea-socks-6 - For info (Please discuss on INTAREA list)
    draft-leddy-6man-truncate - For info (Please discuss on 6MAN list)
    draft-eastlake-sfc-nsh-ecn-support - For info (Please discuss on SFC list)

3. Transport and Network

3.1 Roland Bless: Lower Effort PHB to WGLC
    draft-ietf-tsvwg-le-phb

The WGLC started end of May, but several reviews already on earlier versions.
New comments from Brian Carpenter and David Black. Fred Baker had asked for
discussion on updating RFC 4594.

Fred B: If we are going to rev RFC 4594, there are quite a few things we would
need to fix in association. David B: We should make just enough of an update to
point to the new DSCP. Fred B: I can make a 4594bis... David B: That can be
valuable, but it is a can of worms. Fred B: I think we should enumerate the
worms. David B: I think we should start with a draft that is contained in scope.

Other changes to the LE PHB draft include adding "scavenger class", more
history, and references.

Need to still address Toerless's comments on multicast to avoid replication of
LE packets to busy ports Suggested to include DSCP and Scavenger in the
document title, not done so far in this revision. Issue of MISSREF needs to be
resolved Going to submit a -06 version in the next week or so.

Gorry F: It is worth calling out DSCP and Scavenger in the title to help people
find the RFC. Brian Carpenter: When it gets to AUTH48, we can also add keywords.

Gorry F: Regarding multicast, I think it would be good to include something,
but the text should be limited to "if you're doing multicast, consider
this...". This document does not need to specify everything, but make sure it
is considered. Roland: Toerless has offered to help.

Chairs: To conclude, this draft has already passed WGLC, and any new comments
should be made to the WG.

3.2 Tom Jones: Datagram PLPMTUD
    draft-ietf-tsvwg-datagram-plpmtud

Updated requirements based on Magnus's feedback.
Simplified black hole detection, etc.
More figures to describe several aspects of the algorithm, updated state
machine, etc.

The terminology "effective path MTU" was too much to say, so we call it PLPMTU
"packetization layer PMTU". Replaced ICMP verification with validation. We
think validation is the correct words.

David B: The changes look good. Will you or Gorry read this draft against the
INTAREA tunnels draft to make sure they are reconciled in terminology?

Gorry F: (as author) The terminology within the IETF is messed up - there are
many different terms for slightly different things. As an author, we will refer
to current RFC terms and look to the INTAREA draft to see if they can be
reconciled. We will explain how the terms are used. David B: Good, I just do
not want the same term used differently in both drafts.

Ron Bonica: In INTAREA we have the same problem with a multiplicity of terms.
It could be useful to have a terminology only document. Ron volunteers to do
this. Tom: As long as you use our terms... Some key terms are: PLPMTU (output
of algorithm), BASE_PMTU, MPS (application size), PROBED_SIZE, Actual PMTU.

Update on feedback from Igor, Magnus, Timo. Mainly issues with the state
machine.

The next rev will include changes to the text on  PTB processing (ICMP).

With regards to QUIC, we have had a lot of discussion on PTMU in QUIC, and did
some work at the IETF Hackathon. It is entirely possible using existing
mechanisms in the QUIC protocol. Load balancers may need more state to handle
PTB. Any QUIC probes that go to load balancers will need to carry both IDs.

We will need to write careful text about error states and being resilient to
broken networks. Targeting the November meeting for updates.

Igor L: Thanks for working with us to improve this; with regards to error
states, generally due to PTB that should not be the case, I would equate to bad
ICMP in the network (destination unreachable that is not plausible).

David B: One thing to consider is misconfigured tunnels, which is rare for
IPv4, but more common for IPv6.

Gorry F: An example of an error that can arise is when an endpoint tries to
send a packet of size 1000, and the PTB reports a link MTU of ~700, but
actually probing shows the path supports 1000 B packets. So there may be cases
in which that *can* work.

Another thing to announce is that we have several implementations that we are
working on. Good to know there is code there. Let us know if you want to play
with the code.

Michael Tuexen: We also have implementation for UDP/SCTP.

Chairs: We expect an updated draft soon, please discuss this on the list.

3.3 Ron Bonica:  Destination Originates ICMP PTB Messages
    draft-leddy-6man-truncate

Sometimes ICMP PTB message cannot make it back, e.g., bad firewall filters
(home routers), or other less common issues. An endpoint can see persistent
black holes if the source does not update the PMTU. An ICMP PTB from the
destination node is more likely to make it all the way through the network than
an intermediary node.

The ID adds a truncation eligible option and truncated packet option.
Another option was suggested by TSVWG list, to indicate truncation eligibility
and creates a large padded packet, and indicates how many bytes are not
padding. The destination can check how much was truncated and how much useful
data actually made it across. At least you learn PMTU, and you may get useful
data too.

Is this work interesting without the padding trick?
Is the padding trick interesting?

Tim Shepherd: Why the packet not dropped?
Ron B: Because it has the truncation option...?
Tim S: Well any legacy device would drop it right?
Ron B: Good point, that is safe but not useful.
David B: We should think more about incremental deployment.

Igor L: If the packet makes it to the destination, some applications can
certainly still use data even when truncated. For the assertion that the
destination will be able to get ICMP back, we need to test that.

Tom Jones: I think adding the proposed bits is required, because TCP doesn't
have a length field, and relies on the IP header to know the TCP segment size.
Ron B: I will update the draft with the extra option data. Tom J: There are
many revs as a new draft, so will this settle down to be implementable?

Mirja K (as individual): Why do we not we put the padding directly in the
option? (The "bad idea" fairy brought this.) Ron B: The reason why is that the
max size of padding is 255 bytes. So could not pad out to larger sizes.

Michael T: A modified packet would be dropped with a bad checksum right?
Ron B: The padding would not be protected by the checksum. Should the packet be
correct before or after padding? Gorry F: I think we need to be really careful
that the transport does not misinterpret the padding and/or accept truncated
data - for TCP this may be more difficult that it first seems. --Open question
on this, thoughts both ways.

Fred B: You want the router to disobey current IPv6 processing in an RFC and
then look at an option after the HBH option. Ron B: There is precedent for this
in the RFC describing encapsulation max.

Fred B: Also, you mentioned address-based NATs; also consider port-mapping NATs.
Ron B: This draft does not specify how to communicate up to the higher layers.
Fred B: You will need to address that somehow.

Al Morton: I was shocked to see that you would overwrite the extension header
with another type! Ron B: This is, indeed, the stretch. Al: This makes me
concerned about what the IESG could think! Ron B: It is a big deal to modify an
extension header; as is truncation! Could be better than dropping?

Bob Briscoe: On the topic of incremental deployment, we need a way to do this
without losing the packet. Something like racing things. Looking at stats on
dropping packets based on dest option, it's at 12-17%. Even if this is
supported, it will have trouble getting through the network.

Gorry F: This interesting to explore! Needs more thinking, I think solving the
racing and transport issues are important - and that work seems relevant in
TSVWG, and very related to PLPMTUD.

3.4 Jana Iyengar: Transport mechanisms in QUIC (10 minutes)

Sharing QUIC congestion control and recovery. Premise is that QUIC is different
from TCP: send order is separable from delivery order; packet numbers increase
monotonically; receiver states ack delay; communicates largest acked; and has
different ECN signalling.

Loss Detection has fast retransmit and early retransmit that look similar, but
different. Has tail loss probe, which has not been finished for TCP.

Currently doing editorial work, adding more rationale, etc. Will present more
in TSVWG, TSVAREA, or TCPM in Bangkok

Gorry F: We're not discussing QUIC protocol here, but we can take questions at
the mic.

Randall: If you look at the RACK draft, it does have Tail Loss Probe
Michael T: Why not use RACK?
Jana I: We could in theory. QUIC loss recovery covers RACK/is RACK. Covers
time-based things. Because packet numbers increase in QUIC, that provides time
ordering. Not exactly RACK for QUIC, but covered. Yoshi: Is this really
NewReno, or something based on NewReno that's trying to go beyond or be better?
Jana I: The loss detection mechanism is different, but the CC (I believe) is
NewReno, with minor modifications. Jana I: CC uses NewReno but with
largest_acked for the recovery period.

3.5 Magnus Westerlund: Update on ECN in QUIC

There was a design team for ECN in QUIC, and many changes via editing
New ACK_ECN frame with counters for different marking types in the ack.
Validates ECT on the path and processing on the peer endpoint.
It does continuous validation of the values to deal with path changes:
We do not want to falsely think markings are getting through.
There are some outstanding issues for optimizing the ACK format; recently
merged continuous verification; and open issue for lying receivers

Q1: Can an attacker intercept packets and add markings from the side to mess
with the congestion window. Requires beating the original packet, as long as
only marking on original packets are accepted.

Q2: Will you have ECT(0) and ECT(1) mixed in the same flow?
David B: We need to see where L4S goes with the use of ECT(1).
Bob B: The approach in AccECN is that the receiver is a dumb reflector. There
is also the question of how quick QUIC deployment will be, as relative to TCP.
If we allow both codepoints, we can upgrade more, we do not need to worry in
the same way.

I think you do need to report if you expect ECT(0) and you then get ECT(1).

Jana I: You can have a complex ACK in QUIC, so part of the question is how we
encode the bits to get the most accurate reflection back. Colin Perkins: The
Internet have a history of devices that think they understand TOS; so we may
see these bits transmuting into one another in some networks. So we should have
a reporting mechanism around this. Magnus W: Agreed

Q3: Detecting cheating/lying receivers. Could ignore reporting CE marks to get
more capacity than honest receivers. The network could inject CE marks from the
sender to validate that reports are indeed being made to detect the lie. Bob B:
Is this detection a requirement? Magnus: Just an open issue, not merged yet
Mirja K: (personally) I think any of these recommendations are not QUIC
specific, but should be a separate document. Gorry F: That is one reason I
asked for this to be here, so we can have a broad discussion of ECN apart from
QUIC. Mirja K : I am not sure if the detection of lying is too useful, overall.
A flow is still competing for capacity and CC should be designed to take care
of this. Bob B: It has been suggested that you wait before replying to the CE
(like strech acks) since you may be getting a lot of them. Gorry F: Please
discuss on TSVWG list!

4. Other presentations / New Work

4.1 Colin Perkins/Gorry Fairhurst: Impact of Transport Header Encryption
    draft-fairhurst-tsvwg-transport-encrypt

Transport protocols are beginning to use end to end encryption/integrity for
the transport headers. Goals of the draft is to consider the impact on the way
we deploy and design protocols.

Three revisions since IETF 101; comments from many people; editorial
improvements, and more security considerations.

The editors are trying to provide a neutral and balanced discussion in the
document, without judging encryption as a good or bad thing. Just explaining
what is being done in operational networks and the impacts of encryption on
this. Some comments were added about ossification and other reasons to encrypt
the headers. Some notes added on implications of accountability.

Also added a new security consideration section of the draft, discussing the
implications of avoiding ossification vs exposing information. This summarised
issues explained in the rest of the draft.

There has been clear interest over the past 18 months in IETF WGs. This is
thought useful to take a step back from the focus on QUIC, and look more
broadly and apply general lessons. We believe this is useful to adopt as a WG
draft.

Jana I: Thank you for presenting; not read in detail in recent version, but
definitely intending to read it. Good to see ossification text be added, since
that is such a big part of encrypting the headers. May be good to list out
things that are suffering right now, like TFO and MPTCP deployment due to
middleboxes. These were direct motivators.

David B: Do you think this draft should be adopted by the WG?

Jana I: Is this informational?
Colin: Yes, think so
Jana I: The people working on QUIC should have a look at this and make sure
experience is represented, then yes.

Brian Trammell: Need to read this version of the draft too. I was of the
opinion that this should be adopted. Continue to be so. How do you see this
draft moving alongside IAB work on wire image and path signals? Should we be
working together? Gorry F (from WG mic): I expect the IAB documents will
provide guidance looking ahead... Brian T: We hope to. Gorry F: In contrast,
this document will not provide specific IETF guidance, it documents issues and
history and says what would change if practices change Brian T: The wire image
ID actually refers to this one. I think wire image is close to done (sept/oct).
Give feedback please. Path signals ID is actually older, but may be a bit more
controversial, since it says that you must think about these items. This is the
right WG for this document.

Jabber: How much review and comments on the mailing list have you had?
Colin: Gotten over a half dozen people giving feedback, and some detailed
reviews. It has been presented at several IETF meetings in various areas. David
B: Both authors of the referenced mm-encrypt draft also gave feedback. Mirja K:
The more you go in the direction of being normative, the harder it will be to
get consensus.

Al Morten: I am glad to see the whole slide on neutral point of view. I support
this draft going forward. I will do what I can to help.

Spencer (remote AD): I was pleased to see this document just be descriptive
from the transport perspective. Will help the document be published. Mirja K
(as AD): As a background on the mm-encrypt draft, that RFC was AD-sponsored
without consensus.

Chairs (David): How many people read any version?
    Many hands
Hum for adoption:
    Many
Hum for not:
    Silence

Chairs (David): I believe we will adopt, the decision will be confirmed on the
list.

4.2 Eric Kinnear : TCP Encapsulation Considerations
    draft-pauly-tsvwg-tcp-encapsulation

We presented this at IETF 101 in TSVAREA. It is about IKE in TCP. Expressed
interest in general usage applicability. It is intended to be an informational
reference for anyone trying to tunnel traffic over TCP. The primary thing we
would like to hear from the WG is what are the other cases for doing this and
any other pitfalls the WG may see.

This document does not suggest putting TCP in TCP, does not suggest general
use, does not modify TCP at all, or define a specific protocol.

Motivations: UDP traffic can be blocked or treated badly by NAT timeouts. Are
there others? Encapsulation Format: LV format; again, are there other
suggestions? Also need to make sure you have a port.

The main problem is performance concerns. What can go wrong, and how does a
host may deal with it. Not all concerns have full mitigations, but it still
identifies the problems. Two categories: added unreliability, and problems with
TCP-in-TCP.

Mirja K (as individual): Should we make a stronger recommendation to not try to
modify your protocol on top? Eric K: That makes sense

Terminology: "inner" flows and "outer" tunnel for both layers of TCP. Three
concerns include:
 - Inner TCP experiences outer loss as a delay; delay based congestion control
 can help with that

Brandon Williams: Similar issues were raised in the network coding research
group. That work amplifies the use of delay-based CC. They're also
experimenting with ECN in the inner flows. - Congestion window interactions and
bufferbloat

Bursts of packets created by retransmission, since any retransmission will be
eventually a duplicate. No great solution other than being conservative for
retransmissions.

    - Head of Line Blocking
Any timeout on the other tunnel blocks all other flows. Again increasing the
timeouts on inner flows helps avoid this.

Gorry F: What is the problem with the extra set of segments retransmitted by
the lower layer? Eric K: You are loading too many packets onto the network
after the tunnel. Jana I: We should use the word channel somewhere in here? If
you control the tunnel endpoints, and how you packetize? You can pull the inner
packets out of order. Eric K: We did some experiments in a lab and that did not
help too much, but we should vary more parameters. Jana I: We do not want to
make assumptions about the congestion control.

Colin: We did similar for RTP stuff. We should reference those here. Looks like
same wire format.

Mirja K: Regarding the mitigation techniques, we need to distinguish between
pure end to end, and tunnels for part of the path.

Chairs: How many people read any version?
Handful (6) have read document.

Session II: Thursday Jul-19-2018 1810

Note Taker: Tom Jones

5. Transport Protocols and Mechanisms

5.1 Michael Tuexen: SCTP Drafts
    draft-ietf-tsvwg-natsupp

NATs do not support SCTP in an efficient way. Same method for TCP and UDP, this
gets hard with multihoming and multipath. Changing the port number needs
support for SCTP, because it uses a CRC to protect the data. The document
therefore specified a method for SCTP NAT without changing port numbers.
Status: On 12th version. Comments addressed and text has been made more
consistent. The document was not split into endpoint/middlebox as this did not
make sense to make two separate sections.

Authors consider it finished, but there are new comments on the organisation on
the list from gorry, including a suggestion of how to reorganise the text to
address endpoint versus NAT implementers. This will be addressed in the next
revision and we then expect Gorry Fairhurst to comment again.

Maksim Proshin: Are you aware of any NAT implementations that support SCTP?
Michael T: FreeBSD NAT supports an earlier version of this.
Maksim P: Linux does not have this.
Michael T: That is so.

Maksim P: NATs can provide some support to SCTP already. I think it would be
really good, if the draft describes what works or breaks for SCTP if a NAT does
not support these new methods. Michael T: It is hard to describe a non-working
NAT box. Gorry F: It would be useful to explain what happens when using a
straight IP NAT that does not change ports. Michael T: Some NATs direct all
unknown packets to a host. This works for SCTP. Randal Stewart: This ID
explains how to support SCTP for NAT implementers. That is not to say what will
happen if you do not support SCTP in a NAT. The BEHAVE working group  would be
a better place to specify that. Gorry F: The BEHAVE work was transferred to
this WG when that closed, so this is the right place to discuss how the BEHAVE
RFCs impact this topic. Maksim P: For SCTP implementers. I want to understand
what will not work if you do not implement the specification. Gorry F: If you
implement the SCTP extensions described in this draft, what happens if you just
do the endpoint association and find an old fashioned NAT. Michael T: Normal
SCTP can work through an IP NAT, and then SCTP associations might break if
there are multiple endpoints behind the same NAT. Tim Shepherd: If packets get
through that  NAT something interesting is going on. Gorry F: What we are
calling a NAT will just map IP address if it does not understand the transport
protocol. Tim S: OK, does that then send unknown packets to an endpoint?
Michael T: I have no idea, how this behaves with two nodes behind the NAT.
Normally the port number would be used to demux, but I have not thought what
would happen. Gorry F: Could you please add some text in the intro to cover
undefined NATs? Michael T: Yes, I can write some warning text.

Chairs: We need people that understand NATs to review this document. Would
anyone review?
  Maksim P and Kyle Larose will review

Chairs: Editors, please submit a revision with this  and we will try to go to
WGLC

5.2 Michael Tuexen: RFC4960.bis
     draft-ietf-tsvwg-rfc4960-errata
     Planning for draft-ietf-tsvwg-rfc4960-bis (now on Charter)

rfc4960-errata has left the WG, as listing consensus on how to address the
errata from SCTP RFCs in the bis document to be published. Not every issue here
is being submitted to the errata system, and this presents a consistent view of
how these are expected to be addressed.. Not the ones which are wrong or
rejected.

The IESG evaluation has a high number of abstains (this is informational) and
the document is now with our AD (Spencer) to decide what to do next. There were
comments that the document is hard to read, specifically because the changes
are ordered by time and some update modify previously updated text.

After looking at this, we think the draft can be made easier to understand for
implementors and other readers. We plan to add a note after each comment that
says whether this is the final proposed text, or text explaining this is
further changed in a later section in the document.

Gorry F: We have discussed this and as the document shepherd I would be happy
with this change. I expect it will improve the readability, and address this
particular set of comments. Please do this as soon as you are able, and I will
speak to Spencer and Spencer will know what to do.

Gorry F: Are you now planning to open a -bis document after this?
Michael T: The plan until this morning was to submit a 00 identical to the RFC.
Gorry F: Yes, this would an appropriate plan.
Michael T: We found out RFC 4960 was processed in nroff, so we will see what we
can do. Maybe submit 00, then submit an 01 with a modern toolchain. Chairs: OK.
I suggest you ask the RFC editor if you need help making an XML version (they
may have tools). Michael T: We will submit -00 as working group document.

5.3 L4S
    Bob Briscoe: ECN drafts
    draft-ietf-tsvwg-ecn-l4s-id
    draft-ietf-tsvwg-l4s-arch
    draft-ietf-tsvwg-aqm-dualq
    draft-briscoe-tsvwg-l4s-diffserv

There was no presentation about draft-ietf-tsvwg-l4s-arch this time.

draft-ietf-tsvwg-ecn-l4s-id

There is a new TCP-RACK-like requirement for a transport using L4S.

The 'TCP-PRAGUE' requirements are updated so that the requirements include that
any cc must satisfy to have the right to use this codepoint in the network.
This signals that this cc is acting in a scalable way and won't cause a queue.

We added a fifth requirement: Scalable CC must count in units time and not in
units of packets. This allows L4S enabled-links to relax their reordering
requirements. Some radio links bond multiple links together to increase
bandwidth, relaxing the ordering requirements allows them to avoid slowing down
to maintain packet order.

Lossy links may need link layer retransmission, and currently that means a
resequencing buffer at the far end of the link. If there is a hole in the
sequence this causes head of line blocking. Allowing reordering within a
certain time this buffer can be removed entirely.

A "MUST NOT" was suggested here so the method can evolve over time. We will be
stuck for 30 years if we do not allow this sort of change.

Gorry F: I do not believe expectation of being stuck for 30 years! True there
are hurdles to rapid deployment, and this is now an important consideration for
the WG to consider. Bob B: How do you know which endpoints will enable RACK?
Gorry F: I want to understand the "MUST NOT" as a chair. That is a significant
change in IETF recommendation, and goes in a direction different to many
existing transport specifications. There are considerations here that need to
be explained to the WG, and the WG as a whole need to decide this, this is not
just a "detail" for the authors.  We also have to figure out sort of existing
applications/protocols might work and what might not. I have concerns about the
impact of tunnels and other transport constructions that may unwittingly expose
apps to odd side-effects. As a WG we must first embrace this, and seek to
understand the implications. Anna Brunstrom: Does rack not also respond to the
first 3 reordered segments. Bob B: This is why I say RACK-like, it could be
something different to RACK. Anna B: Must not detect loss in units of packets,
requires time from the start. RACK mixes this at the start. Yeucheng is going
to reconsider this and discuss this in TCPM. Anna B: I thought the rule was
there to help speed the time or detecting loss. He left that rule because it is
hard to detect some patterns of loss otherwise. Bob B: It is because you do not
have many packets in the first RTT, we are going to try and work it out.

Chairs: There are things here that TSVWG needs to understand and think about -
please do continue to ask for feedback and discuss the implications on the list.

draft-ietf-tsvwg-aqm-dualq

There was no time to discuss this, please send comments on the new text using
the WG list.

draft-briscoe-tsvwg-l4s-diffserv

We have updated this draft. The main purpose is to introduce the idea of
expedited forwarding in dual queue as well as ECN for non-queue building
traffic like DNS or game sync traffic. We could consider departing the
different concepts: Maybe all the other stuff in this draft can die or be
separated out.

Gorry F: Please talk offline with David about this

Bob B: There is a group of people working on this, but I am acting as editor
and it looks like it is only me. This will change in the next few weeks and we
can start to progress. I will now try and get their comments on the list.

Gorry F: Visibility to why and how will be very good. Will this be in Bangkok?
Bob B: Yes

Technical updates

6. New Work

6.1 Yingzhen Qu: IPv6 Reservation Protocol
    draft-han-tsvwg-ip-transport-qos

David Black: IETF has interesting experience with resource reservation
protocols. Anyone doing this will find interesting path diversity issues.

We want an in-band signalling protocol using a extension header.
Meant only for flows with high bandwidth low latency requirements.

Gorry F: The ETSI work items say it will publish a document in August. Is that
still the plan? Yingzhen Q: Yes. Gorry F: Does the IETF have change control for
the protocol? Yingzhen Q: The final document will be public. Gorry F: Is ETSI
publishing further standards in the NCP group or that the end of this work?
Yingzhen Q: We will collect information from the IRTF and see.

Kyle Rose: There is an assumption about the number of flows and it is very
small, what if a small number of flows tries to flood the network Yingzhen Q:
We have authentication for the flow reservation. Bob B: The signalling can be
authentic, but the nodes can be numerous, you need push back from the network.

Bob B: I would like to see in this ID much more time spent on understanding why
this did not happen before rather than assuming it was scalability. Gorry F: We
do have a rich history in the IETF trying this. We cannot forget all the things
we tried in the past with other protocols and what worked and did not. Many
were used only in very specific use-cases. There are new opportunities now as
hardware progresses and the Internet changes, but there are also things that
seem very hard to get right. Yingzhen Q: In-band signalling is not new. The
problem is that the signalling has to processed at almost line speed. Bob B:
You need to look at all the reasons, not just scalability. I was heavily
involved in the work to make this work with BT. It was used quite heavily for
about 10 years then taken out because it had never once said no. Yingzhen Q: If
you know all the pitfalls, we would be happy to change this. Bob B: This was a
pitfall, at the time signalling just was not necessary, and we had standards to
enable various styles of QoS. By the time you get through standards operators
will have so much bandwidth for the things you currently think are large they
will actually be tiny.

Bob B: There are other reasons, RSVP applicability is only some of this. We at
the IETF have all been burned by topic in the past. Yingzhen Q: This is not
only about bandwidth reservation, it also includes queueing and scheduling. Bob
B: So also did RSVP. Yingzhen Q: There are many mechanisms people are trying to
use, and new ways to do this.

Fred Baker: I would respond to Bob Briscoe. What where the issues the previous
time this was proposed? It was proposed in 2005, and never made it to a WG.
From a system design thing it just was not possible to build the system. Gorry
F: I see there are people here to talk to, listen and also explain what can be
done with new technology. There is some homework that must be done. Yingzhen Q:
We will do our homework, and see whether we can build a new technology. Gorry
F: Getting multiple vendor inputs will really help, if you can get a few
different to agree that will be huge. Fred B: At this stage, this could be a
better topic for ICCRG? Gorry F: I agree. However, we need to be able to
consider opportunities for a new signalling protocol, and when we understand
this it definitely would fall within the Charter of this WG. David B: Right
now, this looks like a reservation protocol not a congestion control (CC)
algorithm. Fred B: If you are not doing CC, why are you doing the reservation?
Yingzhen Q: There is also a separate CC draft, these two work together.

Gorry F: Thanks for the presentation. Please continue to talk about this
offline.

5.3 Joe Touch (Remote): UDP Options (postponed to later in the meeting)
    draft-ietf-tsvwg-udp-options

Discussion of timestamps and what is required for TCP.
Tom Jones: Surely hosts can be required to support times, there has been a lot
of work recently to support randomized TCP timestamps in Linux and freebsd. Tom
J: Is the requirement for that a host be able to parse the timestamp option and
not send it? Joe T: We need to look at the requirements.

Tom J: I think discussing the TS reply, as a solution to the PLPMTUD need is
wrong. Joe T: I think TCP could use the TS for this. Gorry F (as individual):
We want a request-response mechanism. Joe T: We were going to put an identifier
in the request and use the timestamp as the identifier, so that you can pair
the requests and responses. Gorry F: We want an identifier, and this has
properties that are not in my mind what a TS offers.

Joe T: I would like to avoid a separate request option and a response option.
Gorry F:  I think we can spare two options.
Joe T: If you are using it on a regular basis it is wasting a lot of space.
Gorry F: That may be okay, the method will not use it a lot - probes to
increase the PMTU need not be frequent. A probe message is always valuable. Joe
T: Let us take that offline. Gorry F: I am going to suggest we talk offline and
go through some of these issues.

Gorry F (as Chair): We are after the session close, the WG has emptied out and
the remote audio is not great. Is there anything else? Joe T: No other comments
here.

Chairs: That concludes the meeting, please do continue these various
discussions on the list, and we hope to see you in person or remotely at the
next IETF meeting.