mail archive Transport Area Working Group
tsvwg.ietf.org
(List home) (Recent threads) (187 other Internet Engineering Task Force (IETF) lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Low traffic list: less than 3 messages per day
- This list contains about 1,203 messages, beginning Mar 2011
- 1 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012
Ad
This email announces the start of a working group last call for draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-s... The last call will run for THREE weeks, ending Friday 20th April 2012. Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs)
Dear Gorry, I have read the document, I have also implemented UDP Encapsulation of SCTP Packets into the sctplib userland SCTP implementation and, of course, I support the document.On 28.03.2012 15:25, Gorry Fairhurst wrote: > This email announces the start of a working group last call for > draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". > > Following the meeting this week, this document is now thought to be > ready to proceed to be published as a BCP. Please send any comments to > the TSVWG list. > > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-s... > > The last call will run for THREE weeks, ending Friday 20th April 2012. > > Emails saying "I support" or "I don't support" publication are also > most helpful in judging the WG consensus. Please let us know if this > draft is useful and seems to provide the correct advice. > > James and Gorry > (TSVWG Chairs) > >Best regards
Dear Gorry, I like the idea and am firmly convinced that this reflects an important use case - (Allow SCTP traffic to pass legacy NATs). I support the document and see no problems with the described approach. Martin -----Ursprüngliche Nachricht----- Von: Im Auftrag von Gorry Fairhurst Gesendet: Mittwoch, 28. März 2012 15:26 An: Cc: Betreff: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 This email announces the start of a working group last call for draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-s... The last call will run for THREE weeks, ending Friday 20th April 2012. Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs)
Hi,
I also read the document and use the approach to handle SCTP packets in the userland implementation when no root privileges are granted.
I think it is very important to get it published as an BCP.
Irene RüngelerAm 28.03.2012 um 15:25 schrieb Gorry Fairhurst:
> This email announces the start of a working group last call for
> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets".
>
> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list.
>
> The draft is available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-s...
>
> The last call will run for THREE weeks, ending Friday 20th April 2012.
>
> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice.
>
> James and Gorry
> (TSVWG Chairs)
>
I also think that it would be useful to publish this document as a BCP. Greets Hakim Adhari -----Ursprüngliche Nachricht----- Von: Im Auftrag von Gorry Fairhurst Gesendet: Mittwoch, 28. März 2012 15:26 An: Cc: Betreff: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 This email announces the start of a working group last call for draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-s... The last call will run for THREE weeks, ending Friday 20th April 2012. Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs)
Hi,
I have read the document and support its publication. The UDP encapsulation is very helpful to deploy SCTP despite legacy networks and operating systems without a kernel implementation.
Best regards
RobinOn Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote:
> This email announces the start of a working group last call for
> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets".
>
> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list.
>
> The draft is available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-s...
>
> The last call will run for THREE weeks, ending Friday 20th April 2012.
>
> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice.
>
> James and Gorry
> (TSVWG Chairs)
>
James and Gorry,
I support this.
I have read and followed development of this draft for
encapsulating SCTP over UDP. I recognize the need in
this area, and approve of its content as useful, correct
and complete.
With thanks, from Chris Benson, Adax Inc.On Wed, 28 Mar 2012, Gorry Fairhurst wrote:
>> Date: Wed, 28 Mar 2012 15:25:39 +0200
>> From: Gorry Fairhurst
>> To:
>> Cc:
>> Subject: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03,
>> ending Friday 20th April 2012
>>
>> This email announces the start of a working group last call for
>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets".
>>
>> Following the meeting this week, this document is now thought to be ready to
>> proceed to be published as a BCP. Please send any comments to the TSVWG
>> list.
>>
>> The draft is available at:
>> http://tools.ietf.org/html/draft-ietf-tsvwg-s...
>>
>> The last call will run for THREE weeks, ending Friday 20th April 2012.
>>
>> Emails saying "I support" or "I don't support" publication are also most
>> helpful in judging the WG consensus. Please let us know if this draft is
>> useful and seems to provide the correct advice.
>>
>> James and Gorry
>> (TSVWG Chairs)
>>
>>
I just had a look at the draft again, and I'm wondering how the Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit cannot be set. If a userland implementation is used, this is the case on Mac OS X, for example.
Best regards
RobinOn Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote:
> This email announces the start of a working group last call for
> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets".
>
> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list.
>
> The draft is available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-s...
>
> The last call will run for THREE weeks, ending Friday 20th April 2012.
>
> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice.
>
> James and Gorry
> (TSVWG Chairs)
>
AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw socket, but I do not think that this will work for a SCTP userland implementation. Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: I just had a look at the draft again, and I'm wondering how the Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit cannot be set. If a userland implementation is used, this is the case on Mac OS X, for example. Best regards Robin On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: This email announces the start of a working group last call for draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-s... The last call will run for THREE weeks, ending Friday 20th April 2012. Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs) <
On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: > AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw socket, but I do not think that this will work for a SCTP userland implementation.I guess Robins points is the you SCTP/UDP because you don't have the privileges to open a raw socket. Some OSes support the controlling of the DF bit for a normal user, some don't. I'll update the text accordingly. I guess if you can't control the DF bit, you can't do PMTU discovery. So you need to choose a small MTU value... Or use IPv6, which doesn't have this problem. Best regards Michael> > > Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: > >> I just had a look at the draft again, and I'm wondering how the Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit cannot be set. If a userland implementation is used, this is the case on Mac OS X, for example. >> >> Best regards >> Robin >> >> >> >> >> >> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >> >>> This email announces the start of a working group last call for >>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >>> >>> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. >>> >>> The draft is available at: >>> http://tools.ietf.org/html/draft-ietf-tsvwg-s... >>> >>> The last call will run for THREE weeks, ending Friday 20th April 2012. >>> >>> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. >>> >>> James and Gorry >>> (TSVWG Chairs) >>> >
Am 23.04.2012 um 16:49 schrieb Michael Tuexen: > On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: > >> AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw socket, but I do not think that this will work for a SCTP userland implementation. > I guess Robins points is the you SCTP/UDP because you don't have the privileges to open a raw socket. > Some OSes support the controlling of the DF bit for a normal user, some don't.Yes, this results in a privilege issue.> > I'll update the text accordingly. I guess if you can't control the DF bit, you can't do PMTU discovery. > So you need to choose a small MTU value…I agree. Is "you" for you the protocol developer or the user of the protocol. If I, as a user, have enough knowledge about the connection (even without control and without PMTUD) I would like to change the value to increase my performance. Martin> Or use IPv6, which doesn't have this problem. > > Best regards > Michael >> >> >> Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: >> >>> I just had a look at the draft again, and I'm wondering how the Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit cannot be set. If a userland implementation is used, this is the case on Mac OS X, for example. >>> >>> Best regards >>> Robin >>> >>> >>> >>> >>> >>> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >>> >>>> This email announces the start of a working group last call for >>>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >>>> >>>> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. >>>> >>>> The draft is available at: >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-s... >>>> >>>> The last call will run for THREE weeks, ending Friday 20th April 2012. >>>> >>>> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. >>>> >>>> James and Gorry >>>> (TSVWG Chairs) >>>> >> >
On Apr 23, 2012, at 6:06 PM, Becke, Martin wrote: > > Am 23.04.2012 um 16:49 schrieb Michael Tuexen: > >> On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: >> >>> AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw socket, but I do not think that this will work for a SCTP userland implementation. >> I guess Robins points is the you SCTP/UDP because you don't have the privileges to open a raw socket. >> Some OSes support the controlling of the DF bit for a normal user, some don't. > > Yes, this results in a privilege issue. > >> >> I'll update the text accordingly. I guess if you can't control the DF bit, you can't do PMTU discovery. >> So you need to choose a small MTU value… > > I agree. > > Is "you" for you the protocol developer or the user of the protocol.I meant the developer of the SCTP stack... > If I, as a user, have enough knowledge about the connection (even without control and without PMTUD) I would like to change the value to increase my performance. ... then you as a user of an SCTP stack providing a socket API will allow you set the MTU and disable PMTU discovery by using the SCTP_PEER_ADDR_PARAMS socket option as specified in http://tools.ietf.org/html/rfc6458#section-8.... Best regards Michael> > Martin > > >> Or use IPv6, which doesn't have this problem. >> >> Best regards >> Michael >>> >>> >>> Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: >>> >>>> I just had a look at the draft again, and I'm wondering how the Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit cannot be set. If a userland implementation is used, this is the case on Mac OS X, for example. >>>> >>>> Best regards >>>> Robin >>>> >>>> >>>> >>>> >>>> >>>> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >>>> >>>>> This email announces the start of a working group last call for >>>>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >>>>> >>>>> Following the meeting this week, this document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. >>>>> >>>>> The draft is available at: >>>>> http://tools.ietf.org/html/draft-ietf-tsvwg-s... >>>>> >>>>> The last call will run for THREE weeks, ending Friday 20th April 2012. >>>>> >>>>> Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. >>>>> >>>>> James and Gorry >>>>> (TSVWG Chairs) >>>>> >>> >> > >
Ad