Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt

[Fernando Gont <[e-mail]>]

David,

>> I think the spirit of the text in RFC 1122 is that the mechanism
>> (flag + pointer) should not limit the amount of urgent data that
>> you can send... (although, as dicussed on the list some time ago,
>> the concept of "urgent data" is flawed. It's more of a "mark of an
>> interesting point in the data stream")
> 
> Ah, you can do both over a TCP connection: send a terabyte of normal
> data, and send a terabyte of urgent data.  The urgent date is all the
> data before the urgent pointer.  So, just as TCP cycles through the
> sequence space to send a terabyte of normal data, so too it would
> cycle through to send everything in urgent mode.  Since there is only
> one urgent pointer that gets updated with each new packet, as long as
> the urgent pointer points beyond the end of the data in any given
> packet, the TCP connection will remain in urgent mode until it gets
> to the end of the terabyte of data. :-)  This is the technique
> documented in RFC 2675 "IPv6 Jumbograms", section 5.2.
> 
> So, there is no limit on how much data you can send while in urgent
> mode, from either the application or TCP point of view.

I was referring to the fact that there's a limit on the amount of data
you can send as a result of the size of the Sequence Number field, the
TCP window, etc. (i.e., you cannot simply send "any amount of data"
without taking care of the sequence numbers wrapping before you get the
relevant acks, etc.). I thought *this* was what Wesley was referring to,
rather than that of whether it was possible or not to move the UP.

Anyway, issue solved, it seems. :-)

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1