[Tsvwg] Draft tsvwg meeting minutes

[Allison Mankin <[e-mail]>]

TSVWG folks,

Gorry Fairhurst took very good minutes from the IETF 58, and here
they are after a few Chair edits for a quick review before the IETF 
proceedings CD-ROM deadline tomorrow (updates can happen after that, 
just not for the disk).

Everyone who did not send viewgraphs, please do now!  thanks!

Allison and Jon

IETF 58 - Monday, November 10 at 0900-1130
==========================================

Transport Area WG (tsvwg) Meeting minutes

CHAIRS:    Allison Mankin, AM <[e-mail]>
           Jon Peterson, JP <[e-mail]>

Note taker: Gorry Fairhurst ([e-mail])

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

Charter Discussion for TCP working group creation (TCPM) (Jon Peterson)
JP  talked about proposed new charter to allow bug fixes/minor extensions to
TCP and shepherding advancement of TCP documents along standards track.

tsvwg charter is unchanged by this, remains focussed on tactical, homeless
work.

Q: Is PRSCTP not on the tsvwg charter?
Ans: No, because the new charters do not contain items in final review.

Colin Perkins:  Let's be careful the TCPM charter doesn't suck up all the
new research student's papers!
AM: Yes. Large scale issues and major changes (such as FAST) will remain
with tsvwg, that is, where there are wide considerations. The fixes, etc
will go to tcpm. 

------------------------
 "Packet Drop" chunk type (Randall Stewart)
http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt
Talk about packet loss for satellite link, using a link protocol. For SCTP,
this allows the link to distinguish between packet link loss and congestion
loss.

Matt Mathis: How much does SACK change the results?
Ans: It accounts for most of the difference between TCP and SCTP.

AM: Why didn't you use SACK ?
Ans: We used what we had to hand. SCTP also takes more CPU, but this was not
an issue in the presented results (for 2 Mbps).

JP: Comments to the list please.
------------------------
Newreno Update (Sally Floyd)
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-01.txt

Sally Floyd: New Reno has just completed last call. It was now widely
deployed, but still an Experimental STD, so this propose to bring it to
Proposed STD.
Added text on FR; Impatient & slow and steady variants; etc.
Mark Allman responded to WG Last call, and this has been incorporated.

<No comments>
------------------------
Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy)
http://www.ietf.org/internet-drafts/draft-bhandarkar-tcp-dcr-00.txt
Sally: This is suggested to come to the meeting for discussion as an
experimental ID.

Comment: There is also a buffering issue (more packets) at the receiver too.
This needs to be taken into the discussion.

Q: There is an issue in that if you are not sending at a high rate, this is
not necessarily a good thing, since it adds delay.
Sally Floyd: Yes and also takes the hit in cwnd reduction.

Q: What's the worse case RTO? - Where is the breakpoint? At what point does
the RTT rise too far, impacting performance?
Ans: The most aggressive RTO is at least twice the PRTT.

Q: Link retransmission can make PRTT become highly variable. How do you take
this into account?
Ans:  refer to authors...

John Bennet: If you are only looking at re-odering, this is likely to be on
a timescale that is much less than PRTT.
Sally Floyd: As soon as they see a culmulative ACK, they react to it.
John Bennet:  If you knew it was only 20ms of reordering, you may like to
just use this time?
Sally Floyd: There are many papers in this spectrum - this is just one
extreme.

------------------------
FAST TCP (Cheng/Low)
http://www.ietf.org/internet-drafts/draft-jin-wei-low-tcp-fast-01.txt
Should Fast TCP be an IETF Standard (which would be royalty free) or should
it be open to commercialisation? - There's an IPR statement issued <see
slides>.

Scott Bradner: What does the IPR statement do for people who wish to
implement the draft, before it is an IETF STD? How does the IPR work out?
Standards track process is not clear, full standard, etc.
Ans: I don't know the details and logistics of the legal position. The
intention is clear.

Randall Stewart: I work on SCTP, does the IPR also cover SCTP? Would using
it in SCTP violate the patent?
Ans: The current IPR statement applies to TCP.

Scott Bradner: Can we tweak the wording to say all "IETF Congestion Control"
protocols? This constrains it currently to several transport protocols
specified by the IETF, and protects from other uses outside of this scope
(e.g. for specific corporate applications).

Q: If you publish an open Linux source, there are rules for GNU license that
need to be considered.
Ans: We plan to publish the code, the IPR and open source code issues are
different.

<Fast v. Linux Plot>
Q: In this graph did you look at any packet drops?
Ans: Not here.

Q: Do you plan to show a mixture of FAST sharing with Linux and other TCPs?
Ans: We could show one slide at the end.
Q: So you're saying FAST is not fair to Reno?
Ans: No, we can design for any solution. ...The open issue is how to select
the correct parameters to achieve fairness....
Fred Baker: The simple answer is that Reno will push harder than FAST
because of where the knee is. So FAST gives way to Reno when there is
congestion.
AM: Do the graphs show that FAST is giving way to Reno?
Ans: Not these slides, I do have 1 slide (to show at the end).

Matt Mathis: You didn't say that these results are for a lightly loaded
network, so these are places where Reno does bad for other reasons.
Q: What was the other traffic in the "background traffic" in the production
network results?
Ans: They were likely loaded research networks, we didn't have control of
this background traffic.

<comparison slide not shown, no time remaining>

JP, AM: Let's give this some discussion on the list. 

AM: Suggest on list/next time it would be key to show cases with
competing FAST and other TCP.

------------------------
Link-Up Notification (Spencer Dawkins)
http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-linkup-01.txt
Origins of work in PILC WG, and discussion in TrigTran BoF.
LinkUp is now a notification, not a trigger, and it comes from an end
host, not a middlebox. This is now a tsvwg list item.

Comments requested:
    Security and Safeness considerations in the draft?
    Implementable in TCP?
    Interest form other transports

Matt Mathhis: I don't understand where you have a problem: Is this where an
ACK was sent on a link that went down and then was resent? That is, a
duplicate ACK coming back which was the same ACK being sent twice?
Ans: Notification is when you've lost a link for long enough to be in
RTO.
Matt Mathhis: If this ACK is a duplicate of an already received ACK, then
the sender RTO timer is not going to be running. If the RTO timer is running
 - there's outstanding data in flight. So there's not a problem.
Ans: The situation I'm addressing is relevant to long-latency networks
like GPRS, where a sender can send a fair number of packets that are
still queued for a link when it went down - hence the RTO with a
lengthy backoff.

Mark: Let's talk about this afterwards.
Ans: OK,

Q: Is there an assumption that the link symmetrically goes up and down?
Ans: Either the links go up and down symmetrically, or it's harder to send
an ACK than a data segment, as in GPRS..
Q: Can you have links that revert to half duplex, when they fail?
Ans: Not in the environments I've been working in, but we haven't
considered all environments. This is one of the reasons to ask for
input in TSVWG.

Joe Touch: How long can you hold onto the packet? One router holds it -
another path becomes available, data is exchanged, then the link is restored
and trigger acts. What happens?

Ans: The proposal does not address this question in this version of
the draft.

Joe Touch: we need also to consider possible insertion of data into the TCP
stream at the wrong point (i.,e. data packets delayed more than one MSL
could be spliced incorrectly into the receive data).
Ans: Some cellular modems have been known to come up after days and send out
queued packets, allsorts of things could happen.
Ans: Some cellular modems have been known to come up after days and
send out queued packets. The proposal does not address this question
beyond current TCP.

Joe Touch: Packets longer than a MSL should be dropped... Can we specify
these devices MUST NOT hold onto packet state for more than the MSL?
Ans: Makes sense,  and will be included in the next version of the draft.

Q: Can we get a sense of the applications where this is useful
Ans: We've not characterised all types of links.
AM: Is this TCP-specific really, does it apply to SCTP?
Ans: SCTP seems to be most interested in link-down rather than link-up,
because they have alternate paths that they can use, should a link fail. But
this is our understanding of SCTP from a couple
of IETFs back - we're still interested in hearing if this has changed.

AM: Do we finish this here in tsvwg? Should it be in the new TCPM WG? Is it
ready to be engineered?
What other transports is this relevant to?

Mark Handley: DCCP is also interested in link-triggers! It helps to try to
design for the future, not just today's protocols.
Ans: Agree.
Chou: The same issue should also apply to SCTP.

AM: There has been a fair amount of discussion at the IETF. Should this be a
WG item (towards Experimental)?

<Hum taken, and indicated support to do this work. No obvious issues against
this.>

------------------------
Early Retransmit (Mark Allman)
http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-02.txt
<No presentation - withdrawn from agenda due to author travel glitch>

------------------------
IPMP (Matthew Luckie)
http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-02.txt

Scott Bradner: This sounds like OAM for TCP?
Ans: Not really,<listed several differences in approach>.
Scott Bradner:  I was not meaning to be derogatory, I think OAM can be
useful.
Ans: IPMP is different to the tunnel tracing protocols, for instance.
Scott Bradner: OAM is about finding out what your customers are seeing. You
have similar facilities for the TCP sender (rather than the carrier). It may
be worth looking at the other view,  there seems to be so much interest in
OAM these days!

AM: Can people read this ID and send their comments to the list?

Comment: There is some relevant discussions on the IRTF measurements list.
AM: That is an open list, anyone can see it.  Do go to the IRTF list and
look.

------------------------
RFC1323bis (David Borman)
http://www.ietf.org/internet-drafts/draft-jacobson-tsvwg-1323bis-00.txt

This document is well overdue for updating. Important issues need to be
addressed.

Sally Floyd: A non-issue that arises for large windows + timestamps that
arises from the historical way we did things.  There's going to be problems
if you don't change the RTO value calculation which was traditionally (BSD)
measured once per PRTT. You can end up using an RTO calculated only on the
last few measurements. A simple fix is to change the RTO calculation to take
it to account the more frequent information that is available with RTTM.
Ans: Yes, this is a good thing to change, we'll add this to the list.

Chair note: this work would go to the proposed new TCP working group.
------------------------
Priority Promotion Scheme (Naotaka MORITA)
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt

Q: How is feedback provided on packet drops?
Ans: In the work we use RTCP feedback (based on packet loss).
Q: Looking at Security: how do you prevent a sender from just using a high
priority?
Ans: We use two boxes that monitor the correct behaviour of senders, and
take action.

JP: Can we take a hum on whether there is general interest in doing this in
tsvwg.
<hum>
JP: There seems to be rough consensus on doing this in tsvwg.

------------------------
SCTP Chunk Authentication (Michael Tuexen)
http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-00.txt

<bullet 2 on slide about use of IPsec>
Q: Your bullet says an IPsec channel may be used to authenticate control
chunks. Quite what do you mean by this?
Michael Tuexen: I can authenticate an IP packet  using IPsec - either all
the packet contents or none of it...However, SCTP packets are made up of a
sequence of packets or chunks.
To use IPSEC needs me to look for a specific packet chunk in the payload. Is
this possible? 
Can IPSEC look inside a packet?
Comment: This is not possible, now.

Q; Looking at the list of work (replay protection, specs, key negociation),
a lot of this has been done in IPsec. If you use IPsec, you do have to
secure every packet - that's good anyway. So what's the problem?
Comment : There's a reliance on IP address for IPsec - it's better to fix
IPsec than do something new.
Michael Tuexen: If you do this, you need rekeying.
Comment: Ideally you would split the IP address from the SPI values.  If you
know the ID of the sender then this is fine.
Is this function used to add an address? - We don't want a user to see a
leaked address and then be given the ability to hijack the session.
Ans: Yes, that's the case.
Q: How do we then rekey?
Ans: This  amounts to lots of work for TLS....
David Black: Extending IPsec is the best action, it makes the work more
worthwhile. We should have a better way to setup the keys. there is a limit
to the volume of information that you can send with one (manually
configured) key, before it becomes a vulnerability
Ans: Yes - let's not replicate work items...

AM: This is a very lively discussion, but we have no time. This should be taken on
the mailing list. Let's take this to the list and discuss the architecture
and issues.  It could be exciting.
- -----------------------
De-correlated Loss Recovery (Yogesh Prem Swami)
http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-02.txt
http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-01.txt

<No questions>
- -----------------------
Multi-link Transport (Hosei Matsuoka)
http://www.ietf.org/internet-drafts/draft-matsuoka-multilink-transport-00.txt


Randal Stewart: In SCTP, we looked into two networks using two (parallel)
paths for SCTP. There are some very difficult scenarios, have you thought
about the effect of where the bottlenecks may be in the network?
Ans: The last hop link is not optimal. Signaling in the wireless link is
helpful.
Randal Stewart:  That's just at the edge. What happens if we have a core
network that adds a bottleneck in the centre of the network? - The potential
scenarios become very significant...

JP: This is really interesting, but we need to take it to the list, we are
out of time.
------------------------
11:38 Close of meeting

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg



------- End of Forwarded Message


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg