IETF 58 - Monday, November 10 at 0900-1130

==========================================


Transport Area WG (tsvwg) Meeting minutes


CHAIRS:    Allison Mankin, AM <mankin@psg.com>
           Jon Peterson, JP 
<jon.peterson@neustar.biz>


Note taker: Gorry Fairhurst (gorry@erg.abdn.ac.uk)


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


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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-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/draf
t-swami-tsvwg-tcp-dclor-02.txt

http://www.ietf.org/internet-drafts/draf
t-swami-tcp-lmdr-01.txt


<No questions>
-------------------------
Multi-link Transport (Hosei Matsuoka)

http://www.ietf.org/internet-drafts/draf
t-matsuoka-multilink-transport-00.txt



Randall 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.
Randall 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