[Tsvwg] TSVWG session minutes from IETF-70 (Vancouver) - retransmit with payload.

[Gorry Fairhurst <[e-mail]>]

James, et al,

Here are my notes from the meeting. My notes mainly focus on the speaker 
discussion, rather than the slides - so I hope you can make a hybrid of 
the two.  The notes degenerated slightly when I started thinking how 
things may influence the thinking in UDP Guidelines.

Best wishes,

gorry

---------------

IETF-70, Vancouver, BC    *DRAFT*

TSVWG Thursday Nov 6th, 2007

* Documents to have only Chair Comments on
        draft-larsen-tsvwg-port-randomization-02.txt

Lars presented on behalf of the authors. Currently an individual draft, 
but has received comments and ready to issue a WG document after IETF-70.

This document will be reviewed across a range of TSV WGs reviewers from 
DCCP, SCTP (Randy Stewart volunteered), and TSV.

        draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt
        draft-ietf-tsvwg-rsvp-proxy-proto-02.txt
Authors had revise the draft, and were looking for reviewers from TSV.

*  Francois Le Faucheur - RSVP Extensions for Emergency Services
    draft-ietf-tsvwg-emergency-rsvp-04.txt

This document has completed the WGLC.
Lars: Who has read this? (5 people)
Lars: This will go to a one-week WGLC after IETF-70 to confirm the updates.

*  Fred Baker - DSCPs for Capacity-Admitted Traffic
    draft-ietf-tsvwg-admitted-realtime-dscp-02.txt
There are some comments, and some new text, but may then be ready for WGLC.
Lars: Please make sure all comments go via the list.
Magnus: Who has read this version? (few) - We would like to find some 
reviewers.
Bob: I intend to send comments, since this relates to discussions in PCN 
on the use of DSCPs, but those discussions are unresolved.
Lars: Are you requesting this to work with PCN?
Bob: Another option is to use EF.
Lars: What do we need to coordinate this - cross review? more?
Bob: Difficult, we should know something in the next few weeks on how 
this will progress.
Steve (co-chair PCN): We need to assure these align with PCN, and the 
PCN chairs will coordinate.

*  Michael Tuexen - SCTP Socket API
    draft-ietf-tsvwg-sctpsocket-15.txt
The API is stable and implemented on a broad range of systems (except 
Windows). Not all socket options and specific sctp-related functions are 
available on all platforms.
Lars: The intent was to keep this active until the implementations are 
completed.
Michael: We expect only one round of changes, and then may be ready for 
WGLC for IETF-71.
Lars: I think we should make sure implementors acknowledge via email at 
WGLCC confirming they conform would be really good.

*  Preethi Natarajan  - Non-Renegable Sacks for SCTP
    draft-natarajan-tsvwg-sctp-nrsack-00.txt
Draft was presented, and author asked in this could be a WG item.
Lars: how large a problem is the memory at the sender?
: Depends on the use-case.
Lars; is the gain significant that both sender and receiver implement this?
Dave Borman: Could the non-reneged SACK and regular SACK could be 
different? Is it required for both types of ACK to cover all same set of 
numbers?
: You can just report non-reneged (gap-acks are a superset of 
non-reneged ACKs).
Randy: Only report each type of data in separate places? At some times 
it can help in terms of space, and sometimes not. It easier to feed the 
regular SACK information through the SACK paths, and then update the 
non-renegable data. This helps processing.
Lars: This is a clever scheme. I'd like to see the benefits quantified 
before we take this as a work item. This seems to help with memory 
usage, so this needs to be quantified.

*  Bob Briscoe - Byte and Packet Congestion Notification
    draft-briscoe-tsvwg-byte-pkt-mark-01.txt]
Draft was presented. Author asked in this could be informational and 
plans to update a previous Informational RFC, 2309. There are issues to 
be considered.
Sally: I tend to like byte-mode better than packet-mode for AQM. The 
buffer can be carved into various sized slots, so drop-tail routers see 
this buffering anyway (small packets can often be sent using the small 
packet buffer, even when the link is congested with large packets).
	Small packets are often control packets and we'd expect end-to-end 
congestion control, and we'd expect only a small number of packet losses 
per round trip time. Byte mode (Packet-mode is an incentive to use large 
packets, and more robust to a DoS from small packets that do not do CC).
	Queuing can also present inconsistencies to CC.
Joe Touch: The difference between byte and packet mode depends on the 
sort of bottleneck that limit the performance. Whether the queue is in 
bytes or packets depends for example on whether the limit is processing 
header rate, or interface speed.
Lars: I would like to see discussion on the list, and would encourage 
some more feedback from a broader audience on what we may wish to do as 
a community - other people are encouraged to "chime in".
Bruce Davie: This is an informational RFC. We could document the issues, 
and not update the recommendation.
Lars: I am not clear of the recommendation that would be made. I'd like 
to see how this evolves.

*  Bruce Davie - RSVP-over-L3VPNs
    draft-davie-tsvwg-rsvp-l3vpn-01.txt
Draft was presented and there will be a new revision that will address 
some open issues. Added an appendix to identify candidate solutions that 
were not selected, the next draft should be near completion.
Lars: Scott Bradner is working for the TSV area as advisor and reviewer 
on RSVP, to add expertise on this topic.
Bruce: Who has read this rev of the draft? (few).
Lars: The ADs need to discuss where this work needs to be done. Change 
control for RSVP is charted to this WG. This work could be applicable to 
L3VPN.

Lou Berger: Is this a problem that needs to be solved? L3VPN believe 
this should be solved?
How do you solve this? We have a proposal on the table for using RSVP
Lars: I agree. Is this the only way suggested in L3vPN?
...?: I would like to see more text on why RSVP is the best choice. I 
would like to see more clarity on why RSVP is a good choice compared to 
other options (that include not modifying RSVP).
Lars: If TSVWG takes on this work, we will want consensus from L3VPN 
that this is the correct approach. We need to check this as a pre-requisite.
Dimitri: The basic session processing needs to be discussed.
Ferit Yegenoglu: I think this is a real problem. Does this also apply to 
IPv6? Should this solution be dependent on a specific technology, or 
appropriate to other P2P encapsulations?
Bruce: Expected to also support other tunnel encapsulations.
Lars: An architecture is better than one specific solution.

*  Francois Le Faucheur - A framework for RSVP Security using dynamic 
group-keying.
    draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt
Draft was presented, aimed at informational. Uses dynamic RSVP group keying.

Lars: What is the status draft-weis-gdoi-for-rsvp?
Francois: It depends on this working group.
Lars: What are they waiting for?
Francois: A statement of need from TSV.
Brian Weis: We have heard the work could be done, if there is a need.
Andrew: This brings together all the aspects of security in one place. 
It would be interesting to expand encryption and use of IPsec tunnels 
with RSVP.
Francois: We would be interested in encryption.
...?: Yes we'd be willing to do this.
...?: I think this is a solution to RSVP issues.
Lars: This can is within TSVWG's charter. We have a charter item that 
lets us work on RSVP.
Magnus: We shall do a consensus call on the Agenda.

Lars: I want to tease out the relationship between the two drafts, and 
whether there is an intended solution being proposed (which would be a PS).
Francois: It will investigate the pros and cons, and will not specify 
one specific solution. draft-weis is expected to be one of these.

*  Lars Eggert - UDP Guidelines
    draft-ietf-tsvwg-udp-guidelines-04.txt

Draft was presented, aimed at BCP. Received reviews from range of areas 
within the IETF. New section

...?: What do you do if you have a protocol that runs over UDP and it 
has to run over a NAT. What do you do if you have a protocol that sends 
large packets and the NAT can not support them. The most widely deployed 
NAT traversal is for UDP, so it would be nice to run many protocols over 
UDP.
Lars: You should do IP fragmentation, or do fragmentation in the 
application.
So do we need to define a fragmentation layer above UDP?
Lars: The draft says something of this: IP fragments are bad for packet 
fragmentation.
HIP currently runs over IP. HIP wishes to specify this over UDP to 
improve NAT-Traversal, does it rely on IP fragmentation.
P2P also has this.

<at this point I lost the detail, because I started thinking>

Lars: Such applications will eventually need a session-based transport 
protocol.
Magnus: if we define a new mechanism, then we can not retro-fit this to 
existing applications.
Colin Jennings: Various working groups are defining how to build this 
lower-layer shim.
Lars: This is a BCP, not a requirements for a new protocol spec.

Gorry Fairhurst: You need a set of techniques if there are more than a 
few packets per fragment... It is not just breaking packets up, you have 
to deal with fragment loss, numbering, reassembly, etc.
Lars: Fragmentation is one of a number of unter-related things, you need 
to also consider the rate, congestion-control (so you do not harm the 
performance of the service.
Bryan: Where is the boundary between a simple UDP-based protocol, and 
one that transmits a burst of fragments (say 8KB for NFS), what is 
considered a large burst?
Lars: ...
Philip Mathews: It's not an easy thing to do, we're going to end up with 
a whole bunch of problems if we use IP Fragmentation (including security).

Magnus: We may need to clarify what the best current practice is for 
tunnels using UDP, based on what is in mboned.
Lars: yes, if we know what the best prcatice is.
Gorry: And that may be a different thing to consider for IPv4 and IPv6.

Magnus: Milestone was March. I think you should do one more review cycle 
and then move to WGLC.

WG Closed.