headers
Mark Allman | 1 Feb 2008 04:13

Re: SCTP, but not TCP: immediate SACKing of duplicate data


> I dug through email archives but just couldn't find
> the answer to this one:
> 
> Both RFC 2960 and 4960 specify:
> 
>    When a packet arrives with duplicate DATA chunk(s) and with no new
>    DATA chunk(s), the endpoint MUST immediately send a SACK with no
>    delay.
> 
> and explain this as follows a bit further below:
> 
>    Normally, receipt of duplicate DATA chunks will occur when the
>    original SACK chunk was lost and the peer's RTO has expired.
> 
> This seems to me to be a reasonable choice (e.g. for DSACK
> based spurious timeout detection, and please forgive my TCP
> language here).
> 
> What leaves me confused is: how can this be a good idea for
> SCTP, but not for TCP? (the 2581bis document doesn't seem
> to have this rule).

2581bis does not take into account SACK at all.  So, that is probably
the real answer to your question.  

However, the document does say:

    A TCP receiver SHOULD send an immediate duplicate ACK when an out-
    of-order segment arrives.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 1 Feb 2008 17:54
Picon
Favicon

Adopting an update of the port registration rules in RFC 2780 as WG item?

Hi,

In Vancouver Michelle Cotton (IANA) presented about the desire to revise 
the port registration rules. See the slides and minutes for more info:
http://www.ietf.org/proceedings/07dec/slides/tsvarea-1/sld1.htm
http://www.ietf.org/proceedings/07dec/minutes/tsvarea.txt

Since then, IANA, we ADs, and some IETF participants include transport 
directorate members have continue discussing this and started preparing 
a document to accomplish this update.

As this work seems a good fit to TSVWG we ADs would like to determine if 
there is consensus to adopt this work as WG item? Please provide your 
input into the question.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Marshall Eubanks | 1 Feb 2008 17:57

Re: Adopting an update of the port registration rules in RFC 2780 as WG item?

Is the plan to continue to have a _paid_ expert ? Is there really  
enough work to
justify that ?

Regards
Marshall

On Feb 1, 2008, at 11:54 AM, Magnus Westerlund wrote:

> Hi,
>
> In Vancouver Michelle Cotton (IANA) presented about the desire to  
> revise the port registration rules. See the slides and minutes for  
> more info:
> http://www.ietf.org/proceedings/07dec/slides/tsvarea-1/sld1.htm
> http://www.ietf.org/proceedings/07dec/minutes/tsvarea.txt
>
> Since then, IANA, we ADs, and some IETF participants include  
> transport directorate members have continue discussing this and  
> started preparing a document to accomplish this update.
>
> As this work seems a good fit to TSVWG we ADs would like to  
> determine if there is consensus to adopt this work as WG item?  
> Please provide your input into the question.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 1 Feb 2008 18:04
Picon
Favicon

Re: Adopting an update of the port registration rules in RFC 2780 as WG item?

Marshall Eubanks skrev:
> Is the plan to continue to have a _paid_ expert ? Is there really enough 
> work to
> justify that ?
> 

Hi Marshall,

The plan is to get rid of the paid expert. And clarify the rules and the 
guidance regarding port registrations.

We are not talking any monster document here, but we need something that 
updates RFC 2780. Taking this on in the transport area seems to be a 
good fit and should also result in more input than what an AD sponsored 
document would.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 4 Feb 2008 15:45
Picon
Favicon

Re: I-D Action:draft-ietf-tsvwg-port-randomization-00.txt


Why not make it BCP? This doesn't spec a change that both ends need to
coordinate, or even a change that affects the protocol itself anyway.

Joe

Mark Allman wrote:
|> But for a PS document, I think there needs to be a recommendation
|> made. Otherwise, if this is only to be a survey, Informational would
|> seem to be more appropriate.
|
| I didn't know (or had forgotten) that this was tracked as PS.  I am not
| sure what I think about that.  I look at this sort of like the syn
| cookies document (informational), since it is about an internal
| implementation function.  If going PS means we have to pick one
| algorithm then I think we should go informational.  We may all have our
| leanings about which algorithm is "best", but it seems to me that these
| algorithms are all similar enough and provide the same sorts of
| high-order protection that picking *one* is going to be both tough and
| useless.  I don't think that is something the IETF should spend energy
| on.
|
| I think Fernando's notion of saying port randomization SHOULD be done in
| some fashion and then simply sketching the ways it could be done is
| fine.  I like Lars' added notion that providing a small framework for
| what constitutes a reasonable solution to this problem is fine, too.
|
| allman
|
|
(Continue reading)

Permalink | Reply | 5 comments |
headers
Lars Eggert | 4 Feb 2008 15:54
Picon
Gravatar

Re: I-D Action:draft-ietf-tsvwg-port-randomization-00.txt

On 2008-2-4, at 16:45, ext Joe Touch wrote:
> Why not make it BCP? This doesn't spec a change that both ends need to
> coordinate, or even a change that affects the protocol itself anyway.

Sounds reasonable, especially if we aren't recommending one specific  
algorithm but instead are recommending a set of properties that an  
algorithm should have.

Lars
Permalink | Reply | 4 comments |
headers
Mark Allman | 4 Feb 2008 15:56

Re: I-D Action:draft-ietf-tsvwg-port-randomization-00.txt


> On 2008-2-4, at 16:45, ext Joe Touch wrote:
> > Why not make it BCP? This doesn't spec a change that both ends need to
> > coordinate, or even a change that affects the protocol itself anyway.
> 
> Sounds reasonable, especially if we aren't recommending one specific
> algorithm but instead are recommending a set of properties that an
> algorithm should have.

Yep.  If the "randomize ports, please" is the BCP and not the exact
method for doing it then I'd be in favor of that path.

allman
Permalink | Reply | 3 comments |
headers
Internet-Drafts | 5 Feb 2008 10:15
Picon
Favicon

I-D Action:draft-ietf-tsvwg-udp-guidelines-05.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           : UDP Usage Guidelines for Application Designers
	Author(s)       : L. Eggert, G. Fairhurst
	Filename        : draft-ietf-tsvwg-udp-guidelines-05.txt
	Pages           : 26
	Date            : 2008-02-05

The User Datagram Protocol (UDP) provides a minimal, message-passing
transport that has no inherent congestion control mechanisms.
Because congestion control is critical to the stable operation of the
Internet, applications and upper-layer protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent
congestion collapse and establish some degree of fairness with
concurrent traffic.  This document provides guidelines on the use of
UDP for the designers of such applications and upper-layer protocols.
Congestion control guidelines are a primary focus, but the document
also provides guidance on other topics, including message sizes,
reliability, checksums and middlebox traversal.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ramaiah, Chaitra M (STSD | 7 Feb 2008 06:35
Picon
Favicon

Need info about connect behavior at SCTP when backlog limitis reached

Hi All,

  I have a question regarding how connect should behave for SCTP sockets
when the listen backlog is reached. To elaborate, the server opens a 1-1
SCTP socket, binds and listens with a backlog of 1 and does not do a
accept. The client opens two sockets and connects to the server for the
two sockets. The first connect should go through fine as there is room
for one connection indication. What should happen when we issue the
second connect? For TCP the second connect will just timeout and connect
will return ETIMEDOUT after 75 seconds. What should be the behavior for
SCTP? Should it be on par with TCP and just ignore the request or should
it reply back with ABORT for the INIT initiated by the second connect?
Thanks in advance for your reply.

Regards,
Chaitra
Permalink | Reply | 1 comment |
headers
Lars Eggert | 7 Feb 2008 10:44
Picon
Gravatar

Re: I-D Action:draft-ietf-tsvwg-udp-guidelines-05.txt

On 2008-2-5, at 11:15, ext i-d-announce-bounces <at> ietf.org wrote:
> 	Title           : UDP Usage Guidelines for Application Designers
> 	Author(s)       : L. Eggert, G. Fairhurst
> 	Filename        : draft-ietf-tsvwg-udp-guidelines-05.txt

FYI, this version rolls in a number of smaller changes and  
clarifications based on reviews that for the most part were sent  
directly to the authors. Please check the diff at
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-tsvwg-udp-guidelines-05.txt 
  for details.

As far as the authors are concerned, we think we've addressed all  
comments we've received, and we have nothing we'd want to add to the  
document. To us, this looks ready to proceed to WGLC.

Lars (as an author)
Permalink | Reply | 0 comments |

Gmane