headers
Anantha Ramaiah (ananth | 1 Apr 2011 10:07
Picon
Favicon

RE: Content for deprecating source-quench

Fernando,

> -----Original Message-----
> From: fernando.gont.netbook <at> gmail.com
> [mailto:fernando.gont.netbook <at> gmail.com] On Behalf Of Fernando Gont
> Sent: Thursday, March 31, 2011 10:43 AM
> To: Bob Briscoe
> Cc: Anantha Ramaiah (ananth); tsvwg IETF list;
draft-ietf-tsvwg-source-
> quench <at> tools.ietf.org; fernando <at> gont.com.ar
> Subject: Re: Content for deprecating source-quench
> 
> On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe <bob.briscoe <at> bt.com>
> wrote:
> >
> > Personally I think, if an RFC is going to deprecate something, it
> needs to
> > say why.
> 
> I fully agree. The current doc is what it is because at the time the
> idea of formally deprecating ICMP SQ originated, folks argued that a
> kinda a single page document would do. That's it. But I do agree with
> your view.
> 
> 
> > Referencing an email archive is a bad idea.
> 
> Yes. I just asked which option would make you happier. :-) Unless
> somebody yells, I'll incorporate this in the current Section 2 of the
> I-D.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Briscoe | 1 Apr 2011 11:25
Favicon

RE: Content for deprecating source-quench

Anantha,

At 09:07 01/04/2011, Anantha Ramaiah (ananth) wrote:
>Fernando,
>
> > -----Original Message-----
> > From: fernando.gont.netbook <at> gmail.com
> > [mailto:fernando.gont.netbook <at> gmail.com] On Behalf Of Fernando Gont
> > Sent: Thursday, March 31, 2011 10:43 AM
> > To: Bob Briscoe
> > Cc: Anantha Ramaiah (ananth); tsvwg IETF list;
>draft-ietf-tsvwg-source-
> > quench <at> tools.ietf.org; fernando <at> gont.com.ar
> > Subject: Re: Content for deprecating source-quench
> >
> > On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe <bob.briscoe <at> bt.com>
> > wrote:

snip

>That said, I did briefly go through the email archive pointed by Bob,
>but I am afraid I don't necessarily agree with some of the assertions
>that email has made :-
>
>a) "IPsec and tunneling" :- how different is it for any other for any
>other ICMP message. For example ICMP PTB messages?
>
>Also, it needs to be noted that most stacks do check the sanity of
>incoming ICMP messages (as described by RFC 5927). So the robustness
>worries can be alleviated with such checks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kacheong Poon | 4 Apr 2011 07:40
Picon
Favicon

Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00

On 03/31/11 07:36 PM, Randy Stewart wrote:

> Here I think we must agree to disagree and from the list I think
> you are alone here. Most everyone else is supportive of the idea of
> reseting a stream as well as adding. I will let the chairs of course
> be the judge of consensus...

I think this needs to be put in perspective.  What I've heard
so far is that app writers using SCTP does not think that
having SSN reset is a problem.  If I am an app writer and you
ask me this question whether having SSN reset in SCTP is a problem
from app writing point of view, my answer will also be "there is
no problem."  But this is TSVWG, we must also check the proposal
from the transport layer point of view.  This is what I think
is lacking in the discussion so far.  And this is definitely
lacking in the current draft.  The only point raised from the
transport layer point of view I've read is from Tom Petch.  It
is about "unknotting" some network problem.  And this is still
being discussed.

> I think the big question is the in-band/out-ofband one. The
> rest of the stuff I think has rough consensus (but of course thats
> my opinion).
>
> The big question for the in-band proponents is can we come up with an
> alternative mechanism that adds a stream that is NOT out-of-band. If so
> then I think its a possible option.. However if you still must implement
> two mechanism's then I think an out-of-band mechanism is the best approach
> (only one method ;-D)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kacheong Poon | 4 Apr 2011 07:50
Picon
Favicon

Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started

On 03/31/11 11:11 PM, t.petch wrote:

> No, reset is what I have in mind, but the IETF is a bit short
> of transport layer protocols with which to illustrate my point:-(
> so these are (more or less) application layer doing a similar job.
> For example, how many of the BGP restarts (with consequent
> ripple effects throughout the Internet) prior to Graceful
> Restart were caused by TCP problems which a proper
> TCP reset (not the current 'kill the connection') would have
> obviated?  I do not know of any research into that issue
> but if you look at BGP prior to Graceful Restart, then when
> anything went wrong, it more or less had to take the connection
> down and begin all over again with ripple effects etc.  So a TCP reset
> of the kind proposed for SCTP could have been quite beneficial.
> (Usual caveat about my lack of familiarity with the deployed
> use of SCTP).

Can you be more specific about the TCP issue above?  If
I am not mistaken, the BGP graceful restart is because the
other side has restarted, maybe because of an app crash.
This is not about TCP getting out of sync, which I think is
what your idea of a TCP "reset" may be useful.  It is an
issue above the transport layer.  So I am not sure a
transport layer "reset" can help.

> Remember too that the SCTP association may have underlying state
> as part of security which may be expensive or time consuming
> to re-establish which would be unnecessary if all the problem is
> is with SSN/TSN, which is also part of the SCTP state.  (I think
> that implementation error is the most likely cause of getting knotted,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randy Stewart | 4 Apr 2011 12:58

Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00


On Apr 4, 2011, at 1:40 AM, Kacheong Poon wrote:

> On 03/31/11 07:36 PM, Randy Stewart wrote:
> 
>> Here I think we must agree to disagree and from the list I think
>> you are alone here. Most everyone else is supportive of the idea of
>> reseting a stream as well as adding. I will let the chairs of course
>> be the judge of consensus...
> 
> 
> I think this needs to be put in perspective.  What I've heard
> so far is that app writers using SCTP does not think that
> having SSN reset is a problem.  If I am an app writer and you
> ask me this question whether having SSN reset in SCTP is a problem
> from app writing point of view, my answer will also be "there is
> no problem."  But this is TSVWG, we must also check the proposal
> from the transport layer point of view.  This is what I think
> is lacking in the discussion so far.  And this is definitely
> lacking in the current draft.  The only point raised from the
> transport layer point of view I've read is from Tom Petch.  It
> is about "unknotting" some network problem.  And this is still
> being discussed.

Kahceong, we know you are against this.. thats ok.. I understand.. not
sure why.. because I don't see it as a bad thing, neither do
others who have commented..

> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
t.petch | 4 Apr 2011 18:30

Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started

Kacheong

One last time; we are not communicating, I suspect because we have different
experiences and may be we will never have enough of them to
communicate.  You want 'why', protocol details, and to me they are an
irrelevance, I should not be trying to persuade you with them.  I see almost
everything deficient in the ability to perform partial resets which makes
the cost of a failure much higher than it need be so any additional such
function - eg in SCTP - is automatically a good thing; end of story.

My (frequent) experience is of two systems separated by a (wide area) network
(by definition erratic and unreliable even before malicious interventions
are taken into account), getting out of synch, with only way to
recover a full restart when much is lost that need not have been
had there been a partial restart, a reset or various flavours of reset.
So adding that to SCTP is obviously a good idea; end of story.

I am sure the Microsoft knew that a well designed and well implemented
system would not need partial resets; millions of users know better (blue
screens of death, power on resets anyone?) and so Windows has steadily gained
partial restarts, preserving the 'state' (eg database) that has been built
up over days or weeks of running (I suspect that application designers,
meanwhile,
have got an awful lot smarter at checkpointing and restarting).

My experience is that (almost) every piece of software, (almost)
every protocol could be improved by more partial restarts, resets.
When I am a user of a system and it hangs, and I ring the help desk
it is usually
'have you rebooted the system?'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kacheong Poon | 7 Apr 2011 05:13
Picon
Favicon

Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00

On 04/ 4/11 06:58 PM, Randy Stewart wrote:

> Kahceong, we know you are against this.. thats ok.. I understand.. not
> sure why.. because I don't see it as a bad thing, neither do
> others who have commented..

I have been very clear why I have reservation on the proposal.
IMHO it is a wrong design choice to make the transport layer
fatter just for the sake of app layer protocol which does not
really *need* the functionality.  And as I repeatedly pointed
out, we *MUST* look at it from the transport layer perspective,
not purely from the app point of view as described in the
current draft.  And so far for all the example usage given, the
app layer can do the job just as well.  As Michael noted, it
can be done in many ways.

So it is unclear to me why the authors keep pushing this idea
of TSN/SSN reset.  AFAICT, there is no app layer protocol
requesting SSN/TSN reset in IETF.  At best, there are some
"thought" experiments which *may* utilize it although it *isn't
necessary*.  And it is unfortunate that folks with transport
protocol design experience have not jumped in to comment more,
either for or against the idea.  We only have one sided comment
which is from app layer.  IMHO, this is not a good sign to move
forward as there is not enough discussion from more than one
point of view.  It is also unclear to me why SSN/TSN must be
bundled with stream addition.  It don't see that there is any
technical reason.  Is there any?

>>> Hmm.. that would be an interesting approach and an alternative. But the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 8 Apr 2011 20:45
Picon
Favicon

I-D Action:draft-ietf-tsvwg-sctpsocket-28.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-28.txt
	Pages           : 111
	Date            : 2011-04-08

This document describes a mapping of the Stream Control Transmission
Protocol (SCTP) into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-28.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctpsocket-28.txt): message/external-body, 70 bytes
Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 18 Apr 2011 17:46
Picon
Picon

Fwd: TSV Notes from IETF-80 (draft) and TSVWG Current Status 18-Apr-2011


I uploaded draft notes for TSVWG, please check for corrections:
http://www.ietf.org/proceedings/80/minutes/tsvwg.txt

Below is a draft post-meeting status report.

Best wishes,

Gorry

+++++++++++++++++++++++++

RFC Published:

draft-ietf-tsvwg-admitted-realtime-dscp-07 (RFC 5865)
draft-ietf-tsvwg-rsvp-proxy-approaches-09 (RFC 5945)
draft-ietf-tsvwg-rsvp-proxy-proto-11 (RFC 5946)
draft-ietf-tsvwg-rsvp-l3vpn-07 (RFC 6016)
draft-ietf-tsvwg-ecn-tunnel-10 (RFC6040)
draft-ietf-tsvwg-port-randomization (RFC 6056)
draft-ietf-tsvwg-sctp-chunk-flags (RFC 6096)
draft-ietf-tsvwg-dtls-for-sctp (RFC 6083)

---
IDs in RFC Editor Queue:

draft-ietf-tsvwg-emergency-rsvp-15 (MISREF)
Norm. ref to router alert draft (in the INT-area WG, now in WGLC)

draft-ietf-tsvwg-iana-ports
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Harrington | 19 Apr 2011 23:21
Picon

AD review: draft-ietf-tsvwg-rsvp-security-groupkeying-09

Hi,

I have performed an AD review of this document.

Overall, I found the content of this document well written, but have a
few concerns.
I believe these should be fairly easy to resolve.

-- Technical and Process concerns:
1) section 2 last paragraph
"... the RSVP router that
   receives the Path message will be able to authenticate it
   successfully using the group key."
It is important to be consistent in specifying what is being
authenticated. Here "it" appears to refer to a message. Earlier text
in section 2 says "If a group key is used, the authentication
granularity becomes group membership of devices, not (individual) peer
authentication between devices", which seems to indicate a device (or
peer) is being authenticated (or a group of devices).

2) I am concerned with the number of "should" and "should not"
recommendations, using non-RFC2119 keywords in an Informational
document. This feels like you are trying to define a standard or BCP
without using the standards track process. I think the usage of
"should" should be eliminated from an Informational document.

3) Has the WG explicitly discussed acceptability of the IPR terms
related to this document? The RAND terms apply for compliance to the
standard, but this is not being submitted as a standards-track
document. As noted in 2), there are a number of shoulds in this
(Continue reading)

Permalink | Reply | 1 comment |

Gmane